discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Mixing X and GNUstep


From: David Ayers
Subject: Re: Mixing X and GNUstep
Date: Sun, 13 Jul 2003 15:05:27 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

Raffael Herzog wrote:

On 2003-07-12 20:02:36 +0200 David Ayers <address@hidden> wrote:

This is rather strange. It did finish the NSLog(@"NOT document based"); after which it merely has to return NO; yet it takes relatively long before it logs the event.

I had the impression that it logs immediately, but if you say so... :) I'll use printf();flush() in the future.

Using NSLogs is fine! What I meant, is that the last output of NSLog(@"NOT document based"); successfully finished it's output.

Does line 136 of NSDocumentController.m correspond to the return NO; or is it the beginning of another iteration before it logs the bundle? (There seem to be mutliple calls to isDocumentBasedApplicaion).


It corresponds to the line

 NSDictionary *dict = [bundle infoDictionary];

Ok, so you are in a new invokation of isDocumentBasedApplication. But this time, the output of NSLog([NSString stringWithFormat: @"Got bundle: 0x%08lx", bundle]); did make it before the ... oops, my bad. I though the "Received an untrapped event 94" was already part fo the error message.
/me cleans his glasses.


According to the log, bundle is not nil, but the method call segfaults at line #177 of sendmsg.c, in objc_msg_lookup. That's the line:

result = sarray_get_safe (receiver->class_pointer->dtable, (sidx)op->sel_id);

Transscript from gdb after the segfault:

 (gdb) frame
#0 0x4064bd92 in objc_msg_lookup (receiver=0x818d1d0, op=0x403c0768) at sendmsg.c:177
 177           result = sarray_get_safe (receiver->class_pointer->dtable,
 (gdb) print receiver
 $2 = 0x818d1d0
 (gdb) print receiver->class_pointer
 $3 = (struct objc_class *) 0xdeadface
 (gdb) print "LOL!"
 $4 = "LOL!"
 (gdb) print receiver->class_pointer->dtable
Cannot access memory at address 0xdeadfaee <==== AHA!

Yes, check NSObject's dealloc implementation. IIRC we put 0xDeadFace into the class pointer to detect memory manegment errors. It seems to be a retain/release of the bundle's infoDictionary issue.

I think maybe you should use another compiler.

Nope, sorry, my oversight.
/me checks bundle infoDictionary code....

Cheers,
Dave





reply via email to

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