Re: Vespucci crash. NS_COUNT_HACK ?

[Richard Frith-Macdonald]

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.