[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A segfault in deserializeFromInfo().

From: Adam Fedor
Subject: Re: A segfault in deserializeFromInfo().
Date: Mon, 05 Aug 2002 20:27:20 -0600
User-agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.0rc2) Gecko/20020513

Jefferson Harlough wrote:
Adam Fedor <> 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/

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:


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                    | if I didn't, I'd eat it, and you
                                      | know how I hate the stuff.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]