Re: Help with crash log
Re: Help with crash log
- Subject: Re: Help with crash log
- From: Kurt Revis <email@hidden>
- Date: Mon, 27 Aug 2001 14:19:30 -0700
On Monday, August 27, 2001, at 05:47 AM, Andreas Schweizer wrote:
can anybody please help me to interpret the crash log below?
The crashes occur whenever I do a ctrl-click into one of the program
windows to get a context menu.)
I am not an expert at this, but I'll guess...
Thread 0:
#0 0x7081ab94 in _objc_msgSend ()
#1 0x70161f08 in _CFDictionaryGetValue ()
#2 0x73dadb30 in _RemovePortFromNativeWindowMap ()
#3 0x73da5c8c in _QDUnbindPortFromNativeWindow ()
#4 0x737cc4ec in _DisposeMenuWindow__FP16OpaqueMenuHandle ()
#5 0x737cc28c in _InvalidateMenuSize__FP8MenuData ()
#6 0x737cec00 in _InvalidateMenuItems ()
#7 0x737d3934 in _SetMenuItemTextWithCFString ()
#8 0x70da999c in _AdjustCarbonMenuItem ()
#9 0x710036e8 in __NSPopUpCarbonMenu ()
#10 0x70fe6ba8 in -[NSCarbonMenuImpl
_popUpContextMenu:withEvent:forView:]
#11 0x70fe6ff8 in -[NSMenu _popUpContextMenu:withEvent:forView:]
#12 0x70fe7060 in -[NSMenu _popUpMenuWithEvent:forView:]
#13 0x70d855cc in -[NSWindow sendEvent:]
#14 0x70d78d50 in -[NSApplication sendEvent:]
#15 0x70d7548c in -[NSApplication run]
#16 0x70d9799c in _NSApplicationMain ()
#17 0x00002a90 in te ()
#18 0x000029b4 in :)P ()
#19 0x000027f4 in P ()
Well, my first instinct is to blame NSMenu (more specifically the Carbon
menu implementation underneath). Since NSMenu was switched to use
Carbon's menus, a lot of weird little sporadic bugs have cropped up; you
may be running into one of these. Are you doing anything weird with the
context menu--lots of items, long titles, anything like that?
(To their credit, Apple has been fixing these bugs. Who knows, maybe
this will all be better in 10.1.)
Also, as the previous poster stated, you may also be trying to message
an object which no longer exists. It's really hard to tell which one
that might be, though... NSZombie will indeed help.
Thread 1:
#0 0x000102e4 in =xs_objc_ivar_list:,192,32;\ ()
#1 0x0001048c in per_class:(14,2),32,32;\ ()
#2 0x000106c8 in uestQueue head]:f(0,41)=*(14,9) ()
#3 0x0000ca2c in l _makeDelayedRequestsPending]:f(0,30) ()
#4 0x0000d04c in f:p(0,38) ()
#5 0x0000ee04 in p(149,2) ()
#6 0x0000f9c4 in ()
#7 0x709ecc34 in _forkThreadForFunction ()
#8 0x70014f04 in __pthread_body ()
Now, here's where I get confused. Can anyone explain to me why these
function names are so weird looking? Is this just C++ name mangling? (If
this is C++ code, is the top method on the stack trying to fiddle with
the Objective-C runtime, as its name implies? That could definitely
cause problems if you are trying to use Obj-C in another thread. I know
the Obj-C runtime is supposed to be threadsafe but there are surely some
unusual cases where it isn't...)
--
Kurt Revis
email@hidden