Re: Vespucci crash. NS_COUNT_HACK ?

[Dr. H. Nikolaus Schaller]

Part of the problem may be SWK related.

In the last commit, I did change the -valueForUndefinedKey to return
a WebUndefined object (in preparation for JavaScript). This makes
the problem that some code assumes that it returns nil for
-valueForKey if the key is not available. For these objects, keys
are defined by tag attributes, e.g. <tag bgcolor="red"> results in
a value @"red" for the key @"bgcolor".

Therefore some code did call [WebUndefined someMethod] instead
of [nil someMethod].

Cocoa correctly recognizes this and simply prints:

2011-05-13 08:29:52.708 SWKBrowser[36598:a0f] *** NSRunLoop ignoring exception 
'-[WebUndefined _htmlColor]: unrecognized selector sent to instance 0x2f1de70' 
that raised during posting of delayed perform with target 0x160474a0 and 
selector '_layout:'

This may be the SWK part of the problem.

The SEGFAULT appears to be a problem of -[NSException raise] 

Riccardo, can you please try to set a breakpoint on  -[NSObject 
doesNotRecognizeSelector:]  ?

And try

        (gdb) po self

This should identify the object with the undefined selector.

NOTE: I have reverted the change of -valueForUndefinedKey
in SVN revision 33032 so that the exception should no longer
occur - hiding the problem in the exception handler.

Nikolaus



Am 12.05.2011 um 19:28 schrieb 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.
>> 
>> 
>>   
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev