http://codereview.chromium.org/269039 ...
On Wed, Oct 7, 2009 at 11:13 PM, Jeremy Moskovich <jer...@chromium.org> wrote: > 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 <sh...@chromium.org> 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---