Re: Crash in vfs_s_close()

[Pavel Machek <pavel suse cz>]

Hi!

> I was playing with compressed cpio files on fish and soon after that MC
> crashed.  I cannot reproduce this problem.
> 
> Here's the info from the debugger.

It looks bad. Sorry, I probably do not have time to chase it.

> (gdb) where
> #0  0x080aa165 in vfs_s_close (fh=0x8133230) at direntry.c:890
> #1  0x0809e2d3 in mc_close (handle=3) at vfs.c:501
> #2  0x080a968b in vfs_s_free_super (me=0x80c5b60, super=0x81066b8) at
> direntry.c:445
> #3  0x080aa7b3 in vfs_s_free (id=0x81066b8) at direntry.c:1108
> #4  0x0809fbd9 in vfs_expire (now=0) at vfs.c:1200
> #5  0x0809fc3d in vfs_timeout_handler () at vfs.c:1212
> #6  0x080542c7 in get_event (event=0xbffffb00, redo_event=0, block=1) at
> key.c:684
> #7  0x0806748e in run_dlg (h=0x80e36c8) at dlg.c:922
> #8  0x08082c6a in setup_panels_and_run_mc () at main.c:2186
> #9  0x08082e1a in do_nc () at main.c:2262
> #10 0x0808390e in main (argc=1, argv=0xbffffbd4) at main.c:3160
> #11 0x400e3177 in __libc_start_main (main=0x8083760 <main>, argc=1,
> ubp_av=0xbffffbd4,
>     init=0x804b0ac <_init>, fini=0x80aefb0 <_fini>, rtld_fini=0x4000e184
> <_dl_fini>,
>     stack_end=0xbffffbcc) at ../sysdeps/generic/libc-start.c:129
> (gdb) l
> 885
> 886     int
> 887     vfs_s_close (void *fh)
> 888     {
> 889         int res = 0;
> 890         vfs *me = FH_SUPER->me;
> 891
> 892         FH_SUPER->fd_usage--;
> 893         if (!FH_SUPER->fd_usage){
> 894             struct vfs_stamping *parent;
> (gdb) p *((struct vfs_s_fh *) fh)
> $4 = {ino = 0x0, pos = 135272184, handle = 16, changed = 129, linear = 0,
> u = {fish = {got = 0, total = -1}, ftp = {sock = 0}}, magic = -1}

Is "magic" right at this point? Is changed expected to be 129? Looks
strange.

> (gdb) up
> #1  0x0809e2d3 in mc_close (handle=3) at vfs.c:501
> 501         result = (*vfs->close)(vfs_info (handle));
> (gdb) p vfs_file_table[3]->operations->name
> $14 = 0x80be24a "fish"
> (gdb)
> 
> Obviously, FH->ino is NULL, hence FH->ino->super cannot be accessed, not
> to mention FH->ino->super->me.
> 
> I can put a trivial workaround (check for FH->ino), but it looks like a
> bug that we shouldn't hide.

Forget workaround, leave it there for someone else to debug ;-). Or at
least find reproducible testcase.
								Pavel
-- 
I'm pavel ucw cz  "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss linmodems org