discuss-gnustep
[Top][All Lists]
Advanced

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

Re: new crash: TalkSoup startup


From: Riccardo Mottola
Subject: Re: new crash: TalkSoup startup
Date: Sun, 11 Dec 2016 23:03:39 +0100
User-agent: Mozilla/5.0 (X11; NetBSD amd64; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40

Hi,

Fred Kiefer wrote:
Hi Riccardo,

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.

Riccardo




reply via email to

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