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
-~----------~----~----~----~------~----~------~--~---

Reply via email to