[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