That sounds like a great idea!! Note that there are some limits on crash keys, here's the relevant quote from breakpad.h:
""" // User defined key and value string storage. Generally this is used // to configure Breakpad's internal operation, such as whether the // crash_sender should prompt the user, or the filesystem location for // the minidump file. See Breakpad.h for some parameters that can be // set. Anything longer than 255 bytes will be truncated. Note that // the string is converted to UTF8 before truncation, so any multibyte // character that straddles the 255(256 - 1 for terminator) byte limit // will be mangled. // // A maximum number of 64 key/value pairs are supported. An assert() // will fire if more than this number are set. Unfortunately, right // now, the same dictionary is used for both Breakpad's parameters AND // the Upload parameters. """ If you look at the code that logs URLs you'll note that a URL is split over several keys. Best regards, Jeremy On Wed, Oct 7, 2009 at 10:48 PM, Scott Hess <[email protected]> wrote: > > In fixing a Mac bug, I recently added a layer to intercept > -[NSApplication sendAction:to:from:] and make sure a certain message > wasn't forwarded if the target was known to be freed. Since this is > sort of a core function for event dispatch, now we're seeing > crashdumps with my new method on the stack. I don't think it's a new > problem. > > In researching it, I realize that it maybe gives us a hook for > tracking down some very random browser crashers we see, where there's > a stack of generic Cocoa methods. I could register a crash key which > would report the action that is being sent, and the class of the > sender. If there is anything interesting which could be derived about > the potentially-freed target, that could be reported, too. AFAICT, > it's a matter of calling SetCrashKeyValue() and ClearCrashKeyValue() > at the appropriate spots. > > AFAICT, we don't dynamically call SetCrashKeyValue() anywhere, we > mostly just call it a couple times at startup. Is the approach I > suggest feasible? > > -scott > > PS: The kind of backtrace I'm speaking of are those associated with > http://crbug.com/13111 . They used to look like: > 0x9518c688 [libobjc.A.dylib + 0x00015688] objc_msgSend > 0x953fddcb [AppKit + 0x00111dcb] -[NSControl > sendAction:to:] > 0x953fdc51 [AppKit + 0x00111c51] -[NSCell _sendActionFrom:] > 0x953fd2aa [AppKit + 0x001112aa] -[NSCell > trackMouse:inRect:ofView:untilMouseUp:] > 0x953fcafd [AppKit + 0x00110afd] -[NSButtonCell > trackMouse:inRect:ofView:untilMouseUp:] > 0x953fc3b7 [AppKit + 0x001103b7] -[NSControl mouseDown:] > 0x953faaf6 [AppKit + 0x0010eaf6] -[NSWindow sendEvent:] > 0x953c76a4 [AppKit + 0x000db6a4] -[NSApplication > sendEvent:] > 0x95324fe6 [AppKit + 0x00038fe6] -[NSApplication run] > 0x02517eb2 [Google Chrome Framework - > message_pump_mac.mm:482] > base::MessagePumpNSApplication::DoRun(base::MessagePump::Delegate*) > 0x02517f97 [Google Chrome Framework - > message_pump_mac.mm:146] > base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*) > 0x025148f3 [Google Chrome Framework - > message_loop.cc:199] MessageLoop::Run() > 0x0218a0da [Google Chrome Framework - > browser_main.cc:152] BrowserMain(MainFunctionParams const&) > 0x020cadcf [Google Chrome Framework - > chrome_dll_main.cc:603] ChromeMain > 0x00001fc5 [Google Chrome + 0x00000fc5] > > Now they'll have a line like this at the top: > 0x000ec978 [Google Chrome Framework - > chrome_application_mac.mm:83] -[CrApplication sendAction:to:from:] > > That's where I can hook in to record a bit for breakpad. > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
