After updating, fish would immediately die when started in an xterm from
my window manager (wmii) with a message like:
fish: builtin.cpp:3357: int builtin_end(parser_t&, wchar_t**): Assertion `false' failed.
fish: Job 1, “~/code/fish-shell/fish” terminated by signal SIGABRT (Abort)
Starting fish from an existing shell worked, and running it on other
machines that I was only SSHing into worked as well. I did discover that
on one machine starting git from one specific directory
(/home/ian/bml/kernel) would cause this failure, but starting from any
other directory worked as normal. I'm not entirely sure what
circumstances contribute to this failure - starting from a copy of the
kernel directory works fine.
The failure only started with the following commit, which introduced the
assert(false):
commit d788c84440
Made type property of block_t constant and private
Further work towards cleaning up block_t hierarchy
Looking at this fail in gdb:
(gdb) r
Starting program: /home/ian/code/fish-shell/fish
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
fish: builtin.cpp:3357: int builtin_end(parser_t&, wchar_t**): Assertion `false' failed.
Program received signal SIGABRT, Aborted.
0x00007ffff6c82475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
function=0x548520 "int builtin_end(parser_t&, wchar_t**)") at assert.c:81
(gdb) up 3
3357 assert(false); //should never get here
(gdb) p parser.current_block->type()
$1 = FAKE
So this happens when we run an end command for a FAKE block.
The below patch adds an empty case for FAKE blocks to avoid hitting the
assert. I would need to study the code in more detail to understand if
we should even be executing this code if we are in a FAKE block, but
this patch seems to solve the issue for me.
Signed-off-by: Ian Munsie <darkstarsword@gmail.com>
In both in python2 and python3 parse_qs expects str object. In
python2 it worked ok, because self.rfile was open in binary mode and
str in python2 is actually a string of bytes. However in python3 str is
actually string of unicode literals, not bytes and file was still open
in binary mode. Thus, deleting any file with non-ascii byte inside
filename failed in python3.
Also, cgi.parse_qs is deprecated and shouldn't be used.
