It hasn't occurred to me yet that including the current Isolate and Heap might be useful. What data are you hoping to extract from them?
One thing that would be useful would be including *just the base address* of the first page of the "old space" on the managed heap. The first page consists (almost?) entirely of well-known objects at well-known offsets, so e.g. knowing that 0x1230000 is the first page would be totally enough to deduce that (making up random numbers) 0x1230080 is the "undefined" sentinel, 0x1230240 is the EmptyFixedArray, and so on. Similar for the first page of map space; and these days for RO space. But this is a different kind of data: it's small key-value pairs rather than additional heap regions. The difficulty I see around specifically targeting things like maps and SFIs is that by definition we don't know where a crash will occur, and what kinds of objects/pointers we might have at the time of the crash, and we also don't know what additional data about them will be useful for debugging. The obvious workaround is to include "everything" (i.e. follow all nearby pointers), but that very quickly leads to huge dumps. Crashpad does have some heuristics to look at the current register and stack contents and include memory snippets around the locations they are pointing at. That principle is probably as good as it gets, but the heuristics might be tuned a bit. For example, I think it makes sense to randomize the selection (especially when going deeper than one level), so that if you get thousands of crash reports for the same bug, then eventually some report will contain the data that's needed to analyze the situation, without requiring every report to be huge enough to contain everything, and without requiring us to predict what that specific data is that will be useful in that situation. I think it makes sense to leave most of those heuristics V8-independent and put them into Crashpad. That said, there might be some value in adding a few V8-specific extra rules on the V8 side. In general, we are concerned about keeping crash reports small, for several reasons including (1) time/bandwidth/storage required for the upload, and (2) user privacy, as random memory snippets can contain random personal data, so we want to include as few of those as possible. On Mon, Feb 4, 2019 at 8:07 AM irinayat via v8-dev <[email protected]> wrote: > So far I only looked into the details of how crashpad host and client > interact to collect data for a crash, but if we invest into the scenario, > it makes total sense to fix 8740 as well. > > My understanding is that crashpad has two levels of dumps, small and full. > To make the dumps useful I think we should collect the following for v8 > (s[mall] is collected for both small and full) > 1. (s) pages of the system heap that contain the current Isolate object > and a few others, most importantly Heap (need to identify what other > objects might be useful for post-mortem debugging) > 2. (s) pages of the managed heap that contain jit'ed code and JS objects > referenced from the stack at the moment of the crash (how deep would it > make sense to recurse? I'd expect we'd want the maps, SFIs, etc. but what > else?) > 3. (f) all of the managed heap? > > What if the crash is in GC or some other pure native callstack -- what > parts of managed heap could be relevant to collect? > > Are there any records of the prior discussions wrt integration with > crashpad I could look at (bugs, design docs, proposals, etc.)? > > > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
