Re: Help with crash log
Re: Help with crash log
- Subject: Re: Help with crash log
- From: Andreas Schweizer <email@hidden>
- Date: Wed, 29 Aug 2001 16:08:26 +0200 (MET DST)
Kurt,
thanks for the help. I've been able to locate the problem - it was my
own fault... (I was passing a wrong variable to 'malloc' which caused 0
bytes to be allocated -- hard to find because reading and writing into
the not allocated memory did not cause the program to crash...)
The Menu Manager seems to be especially sensitive to these things.
Andy
BTW: I have no idea why the stack trace of the second thread looks so
funny -- I'm not using C++, only C and Objective-C...
On Mon, 27 Aug 2001, Kurt Revis wrote:
>
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