[Top][All Lists]

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

Re: Vespucci crash. NS_COUNT_HACK ?

From: Dr. H. Nikolaus Schaller
Subject: Re: Vespucci crash. NS_COUNT_HACK ?
Date: Thu, 12 May 2011 14:39:35 +0200

Am 12.05.2011 um 13:00 schrieb 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, 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.

The problem appears to be that there is no message being printed for an 
unrecognized selector
as usual. I.e. the debugging tool is broken and triggered by some other broken 

Or, the stack is corrupt (the argList of +[NSException raise:format:arguments:] 
looks quite strange.


reply via email to

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