|
From: Jefferson C. <jef...@gm...> - 2019-10-05 02:58:41
|
Hi,
I just pulled and built Valgrind master branch, and used it to sanitize
a simple C test program (test program is "int main() { return 0; }". In
order to learn more about the Valgrind internals, I thought to step
through bits of it using GDB.
However when I run my program under GDB I get the following segfault:
$ gdb --args $HOME/p/valgrind-build/coregrind/valgrind ~/test
...
(gdb) r
...
Program received signal SIGSEGV, Segmentation fault.
0x00000010033a8103 in ?? ()
(gdb) bt
#0 0x00000010033a8103 in ?? ()
#1 0x0000001003182f40 in ?? ()
#2 0x0000000000000000 in ?? ()
I configured with CFLAGS="-g -Og" so I'm confused as to why I'm not
getting any symbols in the backtrace.
Currently investigating this problem, just wondering if it's expected
behavior for Valgrind and if there's another way to step through it with
a debugger. (That said any segfault is almost certainly a bug, so let
me know if you want me to work toward a patch)
Jefferson
|
|
From: John R. <jr...@bi...> - 2019-10-05 03:43:44
|
> I just pulled and built Valgrind master branch,
On which hardware architecture and operating system?
> and used it to sanitize a simple C test program (test program is "int main() { return 0; }". In order to learn more about the Valgrind internals, I thought to step through bits of it using GDB.
>
> However when I run my program under GDB I get the following segfault:
>
> $ gdb --args $HOME/p/valgrind-build/coregrind/valgrind ~/test
> ...
> (gdb) r
> ...
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000010033a8103 in ?? ()
> (gdb) bt
> #0 0x00000010033a8103 in ?? ()
> #1 0x0000001003182f40 in ?? ()
> #2 0x0000000000000000 in ?? ()
>
> I configured with CFLAGS="-g -Og"
With which compiler?
> so I'm confused as to why I'm not getting any symbols in the backtrace.
The *runtime* auto-configuration code (detect which CPU variant
and its hardware properties) might generate several signals including SIGSEGV.
Figure out why gdb is not showing symbols in the backtrace,
then get beyond the runtime configuration before complaining.
|
|
From: Jefferson C. <jef...@gm...> - 2019-10-05 04:29:13
|
Wow, thanks for the quick reply! :) On 10/5/2019 3:43 AM, John Reiser wrote: > On which hardware architecture and operating system? x86_64, linux > With which compiler? gcc (Gentoo 8.3.0-r1 p1.1) 8.3.0 > > The *runtime* auto-configuration code (detect which CPU variant > and its hardware properties) might generate several signals including > SIGSEGV. > > Figure out why gdb is not showing symbols in the backtrace, > then get beyond the runtime configuration before complaining. The reason the backtrace is truncated is because of some of the vgPlain_disp_run_translations code - the pushq instructions progressively garble the backtrace that gdb is able to report. However the segfault is certainly at dispatch-amd64-linux.S:111. I'll try to figure out why this jump doesn't work. |
|
From: Ivo R. <iv...@iv...> - 2019-10-05 06:02:45
|
Please refer to: https://sourceware.org/git/?p=valgrind.git;a=blob;f=README_DEVELOPERS;h=97f2329059a7b97c83b912984f8431b187a3c303;hb=HEAD#l108 Do "handle SIGSEGV SIGILL nostop noprint" in GDB to prevent GDB from stopping on a SIGSEGV or SIGILL: (gdb) handle SIGILL SIGSEGV nostop noprint I think this SIGSEGV relates to how your program asks the OS to extend the main stack (Google for "SIGSEGV stack extension"). HTH, Ivosh Il giorno sab 5 ott 2019 alle ore 06:29 Jefferson Carpenter <jef...@gm...> ha scritto: > > Wow, thanks for the quick reply! :) > > On 10/5/2019 3:43 AM, John Reiser wrote: > > On which hardware architecture and operating system? > > x86_64, linux > > > With which compiler? > > gcc (Gentoo 8.3.0-r1 p1.1) 8.3.0 > > > > > The *runtime* auto-configuration code (detect which CPU variant > > and its hardware properties) might generate several signals including > > SIGSEGV. > > > > Figure out why gdb is not showing symbols in the backtrace, > > then get beyond the runtime configuration before complaining. > > The reason the backtrace is truncated is because of some of the > vgPlain_disp_run_translations code - the pushq instructions > progressively garble the backtrace that gdb is able to report. However > the segfault is certainly at dispatch-amd64-linux.S:111. I'll try to > figure out why this jump doesn't work. > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Julian S. <js...@ac...> - 2019-10-05 06:06:57
|
On 05/10/2019 04:58, Jefferson Carpenter wrote: > (That said any segfault is almost certainly a bug, so let me know if you want > me to work toward a patch) This one is probably not. It's the simulated main-thread-stack expansion happening. Let gdb pass the fault to valgrind and continue. J |
|
From: Jefferson C. <jef...@gm...> - 2019-10-05 07:25:34
|
On 10/5/2019 6:02 AM, Ivo Raisr wrote: > Please refer to: > https://sourceware.org/git/?p=valgrind.git;a=blob;f=README_DEVELOPERS;h=97f2329059a7b97c83b912984f8431b187a3c303;hb=HEAD#l108 > > Do "handle SIGSEGV SIGILL nostop noprint" in GDB to prevent GDB from > stopping on a SIGSEGV or SIGILL: > (gdb) handle SIGILL SIGSEGV nostop noprint > > I think this SIGSEGV relates to how your program asks the OS to extend > the main stack (Google for "SIGSEGV stack extension"). > Awesome, thanks. I feel a little bit embarrassed for not having read that document first. |
|
From: Ivo R. <iv...@iv...> - 2019-10-05 09:21:27
|
Il giorno sab 5 ott 2019 alle ore 09:25 Jefferson Carpenter <jef...@gm...> ha scritto: > > On 10/5/2019 6:02 AM, Ivo Raisr wrote: > > Please refer to: > > https://sourceware.org/git/?p=valgrind.git;a=blob;f=README_DEVELOPERS;h=97f2329059a7b97c83b912984f8431b187a3c303;hb=HEAD#l108 > > > > Do "handle SIGSEGV SIGILL nostop noprint" in GDB to prevent GDB from > > stopping on a SIGSEGV or SIGILL: > > (gdb) handle SIGILL SIGSEGV nostop noprint > > > > I think this SIGSEGV relates to how your program asks the OS to extend > > the main stack (Google for "SIGSEGV stack extension"). > > > > Awesome, thanks. > > I feel a little bit embarrassed for not having read that document first. Welcome to the land of Valgrind hackers and enthusiasts! I. |