New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add -core_at_* runtime options #134
Comments
From bruen...@google.com on August 10, 2011 08:09:51 Issue 549 has been merged into this issue. |
From bruen...@google.com on September 22, 2011 13:17:17 we'll want the core to be the app context: xref issue #600 |
From bruen...@google.com on February 17, 2013 08:38:09 Labels: GoodContrib |
From bruen...@google.com on November 12, 2013 09:55:40 xref issue #1378 |
From bruen...@google.com on May 05, 2014 18:10:41 For debugging strange self-interpretation bugs on the bots that I cannot reproduce even when I'm on the bot, I'm going to need to get a core dump so I'm going to implement at least some of this feature. I split minidumps off again as initially I will only support ldmps (invoking dbghelp to get minidumps within the process is not working: see issue #549 ). Owner: bruen...@google.com |
From bruen...@google.com on May 05, 2014 20:46:57 *** TODO w/o app context, or at least CONTEXT local var, ldmp is kind of hard to use ChildEBP RetAddr00 1a76d834 6d0adb37 dynamorio!os_dump_core_live_dump+0x26a [d:\derek\dr\git\src\core\win32\os.c @ 7069] Sure, I can use some windbg tricks to manually create a CONTEXT and Here's an example w/ an uninit: bin/drmemory.exe -dump_at_error_mask 2 -dr d:/derek/dr/git/exports -batch -- tests/registers.exe
ldmp logs/dynamorio/registers.exe.6752.00000015.ldmp
|
From derek.br...@gmail.com on December 10, 2010 17:57:56
PR 427729
since our -pause_at_* options won't work well with server apps that close
stdin (plus PR 425335), and our inf-loop alternative is a one-time-only,
we should add an option to create a livedump at each error, w/ some max.
xref:
xref for Linux:
Case 3408: linux: stack dump not working right with 2.6 kernel + newer glibc
Case 4967: linux: SYS_fork not equivalent to glibc fork() anymore
xref for Windows:
Original issue: http://code.google.com/p/drmemory/issues/detail?id=134
The text was updated successfully, but these errors were encountered: