Re: A segfault in deserializeFromInfo().

[Adam Fedor]

Jefferson Harlough wrote:
> > Adam Fedor <fedor@doc.com> wrote:
> >
> > I don't know. It's possible the extra optimization might cause a 
> > problem. You could compile with debugging info using
> >
> > make debug=yes
> >
> > (although that might specifically filter out any -0 options, even if 
> > you include them in CFLAGS, so you might need to do something 
> > different to keep the optimization in).
>
>
> I tried compiling again, except this time using the Make 1.4.0, Base 
> 1.4.0, Back 0.8.0 and GUI 0.8.0 source packages. I compiled the newer 
> packages with CFLAGS set as "-O0 -g3", and used "make debug=yes" as you 
> suggested.
>
> The segfault in deserializeFromInfo() still seems to be occurring when 
> using the example programs from Examples 0.9.7:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 24474)]
> 0x40416cc8 in deserializeFromInfo (info=0xbfffed80) at NSSerializer.m:587
> 587                   keys[i] = deserializeFromInfo(info);
> (gdb) bt
> #0  0x40416cc8 in deserializeFromInfo (info=0xbfffed80) at 
> NSSerializer.m:587
> #1  0x404179b7 in +[NSDeserializer 
> deserializePropertyListFromData:mutableContainers:] (self=0x404e4500,
>    _cmd=0x402d4e08, data=0x812c940, flag=1 '\001') at NSSerializer.m:784
> #2  0x402047d9 in -[GSServicesManager loadServices] (self=0x814d5e8, 
> _cmd=0x402d4bd0)
>    at GSServicesManager.m:638
> #3  0x40203758 in +[GSServicesManager newWithApplication:] 
> (self=0x402d4760, _cmd=0x40286350, app=0x8156cc8)
>    at GSServicesManager.m:418
> #4  0x400b1d94 in -[NSApplication init] (self=0x8156cc8, 
> _cmd=0x402862d0) at NSApplication.m:623
> #5  0x400b1997 in +[NSApplication sharedApplication] (self=0x40285d60, 
> _cmd=0x806d7a0) at NSApplication.m:525
> #6  0x0804c907 in main () at main.m:39
> #7  0x406f2280 in __libc_start_main () from /lib/libc.so.6
>
>
> I'm not very familiar with the internals of GNUstep, so I'm not exactly 
> sure what deserializeFromInfo() specifically does. Could a corrupt 
> datafile, perhaps left over from an earlier attempt (though I believe I 
> cleared out all existing GNUstep-related files before recompiling), lead 
> to such an error? The error appears to be occurring during  or at a call 
> to deserializeFromInfo() from within deserializeFromInfo(). I don't know 
> if this is possible, but could a segfault like that be caused by 
> exceeding the amount of stack space? I'm just not sure what's causing 
> this problem, which seems to be happening with several releases so far.

Looks like a pretty good analysis, from looking at the source.
A corrupted file is a good possibility. Specifically:

$HOME/GNUstep/Services/.GNUstepServices

Perhaps for my sake, you could print the value of 'size' at the point 
where it segfaults. Perhaps I can add a check for a sane value in the 
sources.


--
Adam Fedor, Digital Optics Corp.      | I'm glad I hate spinach, because
http://www.doc.com                    | if I didn't, I'd eat it, and you
                                      | know how I hate the stuff.