Re: VFS, Fish, crash - additional info

[Pavel Roskin <proski gnu org>]

Hi again!

> Hello!
> First - about 4.5.55.
> 1. I tried to
> cd /#sh:ip.addr:/tmp/
> The same effect - segmentation fault.

That's what I expected.  More like some strange software on the remote 
side.  Maybe unusual settings of sshd, or ls is an alias to someting else.

> 2. When mc crashes, it doesn't restore my terminal settings (for example, 
> enter doesn't begin a new line)

It's a known problem.  At least using "-a" should limit the damage.  In
gdb, use "set args -abu" before running mc.  Another approach would be to
connect to an already running process from another terminal using "attach"  
command in gdb.

> 3. I attach last few lines of output of strace (hope this list accepts 
> attachments).

Yes, the list accepts attachments up to 40k.  But the output of strace is 
quite useless, at least without the backtrace.

> 4. After run gdb -e mc, and exexuting such command:
> Program received signal SIGSEGV, Segmentation fault
> 0x400dcc4e in strstr () from /lib/libc.so.6

Recompile mc with CFLAGS=-ggdb3 and run "where" in gdb.

> 5. After terminal settings are gone, I cannot copy/paste backtrace of mc 
> process (besides it hasn't got debugging symbols). Then `reset` and output is 
> gone :)

And then you can run "where" again :-)

> 6. Why in Debian, when I do `ulimit -c` I have "unlimited", but no core files 
> are created in case of segmentation fault? :(

Latest versions of Linux dump core to a file core.pid, where pid is the 
process number.  This is controlled by file /proc/sys/kernel/core_uses_pid 
and enabled by default on RedHat 7.3 (see file /etc/sysctl.conf, option 
kernel.core_uses_pid)

Also search other directories and make sure that you run "ulimit -c 
unlimited" in the terminal where mc is run.

> About 4.5.99a:
> Something is very bad :(
> After
> cd /#sh:ip.address:

Just in case, try omitting the second ":" - it's useless.

> I get header on panel set properly, indicating that I am on remote shell, but 
> my panel contains only slashes(?!). It looks like that:
> ..
> /
> /

Looks like a problem parsing ls output.  You could write a wrapper around 
ls that would log all output somewhere, put it on the remote host, and 
hardcode its name into mc (vfs/fish.c)

Example of the wrapper:

#!/bin/sh
echo "$@" >$HOME/lsargs.$$
ls "$@" 2>$HOME/lserr.$$ | tee $HOME/lsout.$$

Example of the patch:
==========================
--- fish.c
+++ fish.c
@@ -366,12 +366,12 @@ dir_load(vfs *me, vfs_s_inode *dir, char
 
     command(me, super, NONE,
            "#LIST /%s\n"
-           "ls -lLa \"/%s\" 2>/dev/null | grep '^[^cbt]' | (\n"
+           "$HOME/lswrapper -lLa \"/%s\" 2>/dev/null | grep '^[^cbt]' | (\n"
              "while read p x u g s m d y n; do\n"
                "echo \"P$p $u.$g\nS$s\nd$m $d $y\n:$n\n\"\n"
              "done\n"
            ")\n"
-           "ls -lLa \"/%s\" 2>/dev/null | grep '^[cb]' | (\n"
+           "$HOME/lswrapper -lLa \"/%s\" 2>/dev/null | grep '^[cb]' | (\n"
              "while read p x u g a i m d y n; do\n"
                "echo \"P$p $u.$g\nE$a$i\nd$m $d $y\n:$n\n\"\n"
              "done\n"
@@ -548,7 +548,7 @@ static int linear_start(vfs *me, vfs_s_f
        return 0;
     offset = command(me, FH_SUPER, WANT_STRING,
                "#RETR /%s\n"
-               "ls -l \"/%s\" 2>/dev/null | (\n"
+               "$HOME/lswrapper -l \"/%s\" 2>/dev/null | (\n"
                  "read var1 var2 var3 var4 var5 var6\n"
                  "echo \"$var5\"\n"
                ")\n"
==========================

By the way, you could hardcode /bin/ls and see what happens.

Fish is very sensitive to the remote software, and is not quite reliable
because of that.  This must be the reason why its developer Pavel Machek
didn't add "shell link" to the Left and Right menus, unlike mcfs, ftpfs
and smbfs.

Once it works better, it will be in the menu.

-- 
Regards,
Pavel Roskin