- 20 Sep, 2019 1 commit
-
-
Seth Brenith authored
If we can read an object's Map pointer but not any data from the Map itself, we may still be able to accurately describe the object's type if the Map pointer matches one of the known Maps from the snapshot. GetObjectProperties uses that data in one of two ways: - If it is sure that the Map pointer matches a known Map, then it uses the type from that Map and continues as if it read the type normally. - If the Map pointer is at the right offset within a heap page to match a known Map, but the caller didn't provide the addresses of the first pages in Map space or read-only space, then the type of that Map is just a guess and gets returned in a separate array. This gives the caller the opportunity to present guessed types to the user, and perhaps call again using the guessed type as the type hint. Bug: v8:9376 Change-Id: I187f67b77e76699863a14534a9d635b79f654124 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787986 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#63908}
-
- 09 Sep, 2019 1 commit
-
-
Seth Brenith authored
v8_debug_helper attempts to flag known object pointers when it can recognize them, even if the memory pointed to is not available in the crash dump. In ptr-compr builds, the first pages of the map space, read-only space, and old space are always at the same offsets within the heap reservation region, so we can more easily detect known objects. Bug: v8:9376 Change-Id: I04e0d2357143d753f575f556e94f8fd42ce9d811 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783729 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63624}
-
- 31 Jul, 2019 1 commit
-
-
Seth Brenith authored
This is a reland of 517ab73f Updates since original: now compressed pointers passed to the function GetObjectProperties are required to be sign-extended. Previously, the function allowed zero-extended values, but that led to ambiguity on pointers like 0x88044919: is it compressed or is the heap range actually centered on 0x100000000? Original change's description: > Add postmortem debugging helper library > > This change begins to implement the functionality described in > https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit# > for investigating V8 state in crash dumps. > > This change adds a new library, v8_debug_helper, for providing platform- > agnostic assistance with postmortem debugging. This library can be used > by extensions built for debuggers such as WinDbg or lldb. Its public API > is described by debug-helper.h; currently the only method it exposes is > GetObjectProperties, but we'd like to add more functionality over time. > The API surface is restricted to plain C-style structs and pointers, so > that it's easy to link from a debugger extension built with a different > toolchain. > > This change also adds a new cctest file to exercise some basic > interaction with the new library. > > The API function GetObjectProperties takes an object pointer (which > could be compressed, or weak, or a SMI), and returns a string > description of the object and a list of properties the object contains. > For now, the list of properties is entirely based on Torque object > definitions, but we expect to add custom properties in future updates so > that it can be easier to make sense of complex data structures such as > dictionaries. > > GetObjectProperties does several things that are intended to generate > somewhat useful results even in cases where memory may be corrupt or > unavailable: > - The caller may optionally provide a type string which will be used if > the memory for the object's Map is inaccessible. > - All object pointers are compared against the list of known objects > generated by mkgrokdump. The caller may optionally provide the > pointers for the first pages of various heap spaces, to avoid spurious > matches. If those pointers are not provided, then any matches are > prefixed with "maybe" in the resulting description string, such as > "maybe UndefinedValue (0x4288000341 <Oddball>)". > > Bug: v8:9376 > > Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012 > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62882} Bug: v8:9376 Change-Id: I866a1cc9d4c34bfe10c7b98462451fe69763cf3f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717090Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#63008}
-
- 24 Jul, 2019 1 commit
-
-
Zhi An Ng authored
This reverts commit 517ab73f. Reason for revert: Test failures https://bugs.chromium.org/p/v8/issues/detail?id=9538 Original change's description: > Add postmortem debugging helper library > > This change begins to implement the functionality described in > https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit# > for investigating V8 state in crash dumps. > > This change adds a new library, v8_debug_helper, for providing platform- > agnostic assistance with postmortem debugging. This library can be used > by extensions built for debuggers such as WinDbg or lldb. Its public API > is described by debug-helper.h; currently the only method it exposes is > GetObjectProperties, but we'd like to add more functionality over time. > The API surface is restricted to plain C-style structs and pointers, so > that it's easy to link from a debugger extension built with a different > toolchain. > > This change also adds a new cctest file to exercise some basic > interaction with the new library. > > The API function GetObjectProperties takes an object pointer (which > could be compressed, or weak, or a SMI), and returns a string > description of the object and a list of properties the object contains. > For now, the list of properties is entirely based on Torque object > definitions, but we expect to add custom properties in future updates so > that it can be easier to make sense of complex data structures such as > dictionaries. > > GetObjectProperties does several things that are intended to generate > somewhat useful results even in cases where memory may be corrupt or > unavailable: > - The caller may optionally provide a type string which will be used if > the memory for the object's Map is inaccessible. > - All object pointers are compared against the list of known objects > generated by mkgrokdump. The caller may optionally provide the > pointers for the first pages of various heap spaces, to avoid spurious > matches. If those pointers are not provided, then any matches are > prefixed with "maybe" in the resulting description string, such as > "maybe UndefinedValue (0x4288000341 <Oddball>)". > > Bug: v8:9376 > > Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012 > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62882} TBR=yangguo@chromium.org,mvstanton@chromium.org,jgruber@chromium.org,tebbi@chromium.org,seth.brenith@microsoft.com Change-Id: Ia078f2e8d101d2375b5db88021b2d65d28f1b075 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9376 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1716033Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#62899}
-
- 23 Jul, 2019 1 commit
-
-
Seth Brenith authored
This change begins to implement the functionality described in https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit# for investigating V8 state in crash dumps. This change adds a new library, v8_debug_helper, for providing platform- agnostic assistance with postmortem debugging. This library can be used by extensions built for debuggers such as WinDbg or lldb. Its public API is described by debug-helper.h; currently the only method it exposes is GetObjectProperties, but we'd like to add more functionality over time. The API surface is restricted to plain C-style structs and pointers, so that it's easy to link from a debugger extension built with a different toolchain. This change also adds a new cctest file to exercise some basic interaction with the new library. The API function GetObjectProperties takes an object pointer (which could be compressed, or weak, or a SMI), and returns a string description of the object and a list of properties the object contains. For now, the list of properties is entirely based on Torque object definitions, but we expect to add custom properties in future updates so that it can be easier to make sense of complex data structures such as dictionaries. GetObjectProperties does several things that are intended to generate somewhat useful results even in cases where memory may be corrupt or unavailable: - The caller may optionally provide a type string which will be used if the memory for the object's Map is inaccessible. - All object pointers are compared against the list of known objects generated by mkgrokdump. The caller may optionally provide the pointers for the first pages of various heap spaces, to avoid spurious matches. If those pointers are not provided, then any matches are prefixed with "maybe" in the resulting description string, such as "maybe UndefinedValue (0x4288000341 <Oddball>)". Bug: v8:9376 Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#62882}
-