Frame for main() missed in callstack starting in libc #2392
Labels
Comments
|
It looks like the problem is not lack of line number information, but skipping the |
|
Nope. Compile, Run DrMemory, |
|
As a guess, I also tried with |
|
Please try the various callstack options to see if any of them fix the issue: e.g., |
|
Tried the following one-at-a-time with 2.3.18665 and observed no change, Starting back at the beginning, the README says to compile with '-m32' (doesn't work on my system) but the web page does not, https://dynamorio.org/drmemory_docs/page_prep.html#sec_prep_linux So I didn't compile with -m32. More details on my gcc if that matters, |
|
Some of those options are already on by default. Please try |
|
Ugh. Sorry. Tried that first, but missed it in the list. No change. |
|
One more try: Of course that should not be necessary; callstacks in some shared libraries have been a challenge in some situations. Here we have FPO in multiple frames and the build options of the executable seemingly do not come into play as likely once on a false chain the skip over main would happen no matter the a.out layout if it only depends on the libc behavior. |
|
Nope. Any additional logging I can enable? |
E.g., |
derekbruening
changed the title
|
I found a Linux machine where I could reproduce the original issue. For 64-bit, |
|
Logs attached as zip. Compile,
Run DrMemory, |
No for me, |
|
Sorry also needs to be debug build: |
|
Assuming that you meant to combine the last two option recommendations... Nope. Additional system info if it helps, |
I mean for useful logs it needs |
|
I'm confused. Can you please provide the full list of options you want me to run with this time? |
Sorry for any confusion. Earlier you provided a logs zip file, but the logs are rather sparse because it was release build rather than debug build. I was requesting a new logs zip file with a run that includes |
|
No problem. Run below. Logs attached. |
derekbruening
added a commit
that referenced
this issue
Oct 17, 2021
Updates DR to 53af6c7 for the new drcallstack library. Adds a new option -callstack_use_unwind which is on by default for Linux. This uses drcallstack's libunwind-based callstack walk, which fixes problems of missing frames. If the starting PC is not in a module, the old callstack walking is used. Updates malloc replacement contexts to include the PC as of the same point as the captured stack pointer, for proper libunwind input. Issue: #823, #2399, #2392, #1222 Fixes #2392
derekbruening
added a commit
that referenced
this issue
Oct 18, 2021
Updates DR to 53af6c7 for the new drcallstack library. Adds a new option -callstack_use_unwind which is on by default for Linux. This uses drcallstack's libunwind-based callstack walk, which fixes problems of missing frames. If the starting PC is not in a module, the old callstack walking is used. Updates malloc replacement contexts to include the PC as of the same point as the captured stack pointer, for proper libunwind input. Issue: #823, #2399, #2392, #1222 Fixes #2392
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I presume that I'm doing something wrong, but this is pretty basic usage following the documentation.
Here's what I'm seeing,
My compiler,
Compiling with -g for debugging info,
$ gcc -g -fno-inline -fno-omit-frame-pointer test.cVersion of DrMemory (it's in the directory name below too),
Output from DrMemory without a reference to the source code location in test.c,
For comparison, Valgrind points to the source line in test.c,
The text was updated successfully, but these errors were encountered: