Re: Vespucci crash. NS_COUNT_HACK ?

[Riccardo Mottola]

Hi,

the original stacktrace posted comes from latest OpenBSD 4.9 on x86.

I tried now FreeBSD and NetBSD and I get strange hangs... but not the 
crash on OpenBSD. Something got fishy. The application Vespucci doesn't 
even display its main document window on these platforms.
WHen launched inside gdb it just hangs.

If launched without it will hang during the rendering of the 
www.gnustep.org page.

A memory error could explain a behaviour that changes with gdb.

Riccardo

Richard Frith-Macdonald wrote:
> On 12 May 2011, at 11:37, Riccardo Mottola wrote:
>
>    
> > Hi,
> >
> > even if no significant changes were made to SWK and Vespucci lately, it stopped 
> > working properly.
> >
> > Today, if I try to open www.gnustep.org, I get:
> >
> > 2011-05-12 11:33:21.176 Vespucci[32723] mimeType: text/html
> > 2011-05-12 11:33:21.177 Vespucci[32723] expectedContentLength: 5587
> > 2011-05-12 11:33:21.177 Vespucci[32723] suggestedFilename: www.gnustep
> > 2011-05-12 11:33:21.177 Vespucci[32723] textEncodingName: UTF-8
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to process 32723, thread 0x8ae8bc00]
> > 0x04cdd9a1 in NSCountFrames () at NSDebug.m:991
> > 991           _NS_COUNT_HACK(27); _NS_COUNT_HACK(28); _NS_COUNT_HACK(29);
> > Current language:  auto; currently minimal
> >
> >
> > #0  0x0e85e9a1 in NSCountFrames () at NSDebug.m:991
> > #1  0x0e864169 in GSPrivateStackAddresses () at NSDebug.m:1112
> > #2  0x0e87900f in -[GSStackTrace init] (self=0x86aed128, _cmd=0x2e85f308)
> >     at NSException.m:605
> > #3  0x0e8c7992 in +[NSObject new] (self=0x2e8463e0, _cmd=0x2e846460)
> >     at NSObject.m:1159
> > #4  0x0e87992c in -[NSException raise] (self=0x86aed448, _cmd=0x2e8464c8)
> >     at NSException.m:960
> > #5  0x0e878eb4 in +[NSException raise:format:arguments:] (self=0x2e8462e0,
> >     _cmd=0x2e8464b0, name=0x2e846588, format=0x2e85f574,
> >     argList=0xcfbef800 "Û 
> > µ-\034ct.\002\232³-pô\212.\200ò\205.P\235\207\016\002\232³-pô\212.Pó\205.\220\217\214\016Xø¾ÏÎx\214\0168hÍ\206Pó\205.xä³-&{\214\016`!")
> >  at NSException.m:849
> > #6  0x0e879da3 in +[NSException raise:format:] (self=0x2e8462e0,
> >     _cmd=0x2e85f280, name=0x2e846588, format=0x2e85f574) at NSException.m:835
> > #7  0x0e8c903f in -[NSObject doesNotRecognizeSelector:] (self=0x86cd6838,
> >     _cmd=0x2e85f350, aSelector=0x2db3e478) at NSObject.m:1597
> > #8  0x0e8c78ce in -[NSObject forwardInvocation:] (self=0x86cd6838,
> >     _cmd=0x2e894248, anInvocation=0x81b77808) at NSObject.m:1618
> > #9  0x0e985a37 in GSFFIInvocationCallback (cif=0x81b77700, retp=0xcfbef950,
> >     args=0xcfbef8e0, user=0x86aed088) at GSFFIInvocation.m:624
> > #10 0x0fa04a37 in ffi_closure_SYSV_inner (closure=0x7cb00000,
> >     respp=0xcfbef95c, args=0xcfbef970) at src/x86/ffi.c:414
> >
> >
> > What is this error and where it is coming from? The name "count hack" is 
> > certianly not encouraging.
> >      
> The count hack is a workaround for versions of the compiler where the stack 
> count code does not terminate at the top of the stack as it should (or where 
> the stack is corrupt) ... it catches the signal which is raised and recovers 
> from it.
>
> The real error is hinted at by the call to doesNotRecognizeSelector: ... this 
> means that a message was sent to an object which doesn't implement the method, 
> so you really need to look at the higher level calling code to see what it's 
> doing.  often this is caused by sending a message to an uninitialised variable, 
> or to a variable which points to an object which was deallocated and whose 
> memory was then re-used by another object (ie a retain/release error), but 
> sometimes it's something more obvious like having created an object of one 
> class by mistake, and sending a message intended for another class.
>
>
>