Issue 333 in google-breakpad: Provide subclass name with implementor class names in Objective-C backtraces.
codesite...@google.com
Owner: ----
New issue 333 by sh...@chromium.org: Provide subclass name with implementor
class names in Objective-C backtraces.
http://code.google.com/p/google-breakpad/issues/detail?id=333
It would be useful if the stack trace contained the name of the target
object's class in addition to
the name of the class the method is implemented in. We get a number of
crashes where the
stack trace is all Cocoa classes, it would be useful to know if these were
actually the inherited
Cocoa methods in our special sub-classes or not.
For example, a random trace:
0x9295c688 [libobjc.A.dylib + 0x00015688] objc_msgSend
0x91317dcb [AppKit + 0x00111dcb] -[NSControl sendAction:to:]
0x91317c51 [AppKit + 0x00111c51] -[NSCell _sendActionFrom:]
0x913172aa [AppKit + 0x001112aa] -[NSCell
trackMouse:inRect:ofView:untilMouseUp:]
0x91316afd [AppKit + 0x00110afd] -[NSButtonCell
trackMouse:inRect:ofView:untilMouseUp:]
0x913163b7 [AppKit + 0x001103b7] -[NSControl mouseDown:]
0x91314af6 [AppKit + 0x0010eaf6] -[NSWindow sendEvent:]
0x912e16a4 [AppKit + 0x000db6a4] -[NSApplication sendEvent:]
0x9123efe6 [AppKit + 0x00038fe6] -[NSApplication run]
Knowing that the NSWindow in question was actually an OurMagicPopupWindow
and that NSCell
was OurMagicButtonCell would be super helpful.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings