> Am 11.12.2016 um 23:03 schrieb Riccardo Mottola <[email protected]>: > > Fred Kiefer wrote: >> first off, the exception you are getting seems to be happening in the >> [NSLock new] call and this is highly unlikely. Could you please verify that >> you are using versions of gun and base that fit properly together? Or maybe >> you have local changes to base? > > I know it is, but that is why I did a make clean and recompiled with debug > symbols. I have no local differences. > Perhaps something is already corrupt and this is why allocating a new lock > fails. > Or by change, we are around a different aspect of our lock problem. >> >> Even for not document based applications GNUstep initialises an >> NSDocumentController, if that gets used in the code. You have a valid point >> here to question that. Maybe somebody should do a bit of research, wether >> Cocoa does the same. At the moment we read the document class definitions >> inside the NSDocumentController initialisation code and only after that we >> know whether we have a document based application. > > That would be worth knowing! I suppose getting a sharedDocument controller > always returns one, so how can I know I have not one? I wonder about how to > make a simple mac test app. > > >> In your specific case the initialisation of the NSDocumentController happens >> because NSApplication cannot find a suitable responder for an action it is >> trying to send. This looks like your UI is using an undefined message. > > Perhaps identifying what action is useful, but I guess not having a responder > shouldn't cause this sort of crash? At most an exception? > > This doesn't look nice either: > #6 0x0000709d9520fa15 in -[NSApplication targetForAction:] ( > self=0x709d9f9d51c0, _cmd=0x709d9572e180 <_OBJC_SELECTOR_TABLE+5024>, > aSelector=0x709d9e7ec380) at NSApplication.m:2316 > 2316 return [self _targetForAction: aSelector > (gdb) po NSStringFromSelector(aSelector) > Cannot access memory at address 0xffffffff9cf96830 > > perhaps the selector itself is bad? I went up one trace, printed out > theAction and I get again a crash. I fear the memory is very comprimised. > > (gdb) p theAction > $1 = (SEL) 0x7cc64e708f80 > (gdb) po NSStringFromSelector(theAction) > Cannot access memory at address 0x4d72c3b0 > > I was able however to check out which menu it is: > (gdb) p item > $3 = (struct NSMenuItem *) 0x7cc64d3557b0 > (gdb) po item > <NSMenuItem: 0x7cc64d3557b0> > (gdb) po [item title] > Cut > > the application is starting up, perhaps things are not yet connected, I hope > this is normal and is not the cause of the crash. This code used to work > months ago and works on Mac.. so I wonder what changed.
Now this really sounds like corrupted memory. You should stop that level of inspection for now and instead try to run valgrind on your application. Fred _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
