|
From: Siddharth N. <sn...@dr...> - 2012-08-04 22:44:25
|
Hi, I'm running callgrind on a PARSEC benchmark named blackscholes. $ cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.8 (Tikanga) $ uname -a Linux ......edu 2.6.18-308.11.1.el5 #1 SMP Fri Jun 15 15:41:53 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux $ valgrind --tool=callgrind ./blackscholes 1 in_4.txt prices.txt ==3054== Callgrind, a call-graph generating cache profiler ==3054== Copyright (C) 2002-2011, and GNU GPL'd, by Josef Weidendorfer et al. ==3054== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info ==3054== Command: ./blackscholes 1 in_4.txt prices.txt ==3054== ==3054== For interactive control, run 'callgrind_control -h'. PARSEC Benchmark Suite Version 2.1 Num of Options: 4 Num of Runs: 100 Size of data: 160 ==3054== ==3054== Events : Ir ==3054== Collected : 529747 ==3054== ==3054== I refs: 529,747 When I run it normally, it runs fine as shown above. However, when I run it under gdb: $ gdb /usr/local/lib/valgrind/callgrind-amd64-linux GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-42.el5) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/local/lib/valgrind/callgrind-amd64-linux...done. (gdb) b sync_signalhandler Breakpoint 1 at 0x3802d3a0: file m_signals.c, line 2330. (gdb)* r ./blackscholes 1 in_4.txt prices.txt* Starting program: /usr/local/lib/valgrind/callgrind-amd64-linux ./blackscholes 1 in_4.txt prices.txt *warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaaaaaab000* ==3031== Callgrind, a call-graph generating cache profiler ==3031== Copyright (C) 2002-2011, and GNU GPL'd, by Josef Weidendorfer et al. ==3031== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info ==3031== Command: ./blackscholes 1 in_4.txt prices.txt ==3031== ==3031== For interactive control, run 'callgrind_control -h'. PARSEC Benchmark Suite Version 2.1 *--3031-- VG_USERREQ__CLIENT_CALL1: func=0x0 ERROR: Unable to open file `in_4.txt'.* ==3031== ==3031== Events : Ir ==3031== Collected : 137073 ==3031== ==3031== I refs: 137,073 Program exited with code 01. I found this error in some other contexts online, but no resolution. I also see this behavior for other PARSEC benchmarks. Sid P.S.: Verbose version - $ gdb /usr/local/lib/valgrind/callgrind-amd64-linux GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-42.el5) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/local/lib/valgrind/callgrind-amd64-linux...done. (gdb) r -v ./blackscholes 1 in_4.txt prices.txt Starting program: /usr/local/lib/valgrind/callgrind-amd64-linux -v ./blackscholes 1 in_4.txt prices.txt warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaaaaaab000 ==3909== Callgrind, a call-graph generating cache profiler ==3909== Copyright (C) 2002-2011, and GNU GPL'd, by Josef Weidendorfer et al. ==3909== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info ==3909== Command: ./blackscholes 1 in_4.txt prices.txt ==3909== --3909-- Valgrind options: --3909-- -v --3909-- Contents of /proc/version: --3909-- Linux version 2.6.18-308.11.1.el5 ( moc...@hs...) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-52)) #1 SMP Fri Jun 15 15:41:53 EDT 2012 --3909-- Arch and hwcaps: AMD64, amd64-sse3-cx16 --3909-- Page sizes: currently 4096, max supported 4096 --3909-- Valgrind library directory: /usr/local/lib/valgrind ==3909== For interactive control, run 'callgrind_control -h'. --3909-- Reading syms from /home/DREXEL/sn446/projects/accel-metrics-NEW/data/parsec_vgprof/blackscholes/test/blackscholes (0x400000) --3909-- Reading syms from /usr/local/lib/valgrind/callgrind-amd64-linux (0x38000000) --3909-- object doesn't have a dynamic symbol table --3909-- Reading syms from /lib64/ld-2.5.so (0x3d8fe00000) --3909-- Scheduler: using generic scheduler lock implementation. ==3909== embedded gdbserver: reading from /tmp/ vgdb-pipe-from-vgdb-to-3909-by-sn446-on-dragon.ece.drexel.edu ==3909== embedded gdbserver: writing to /tmp/ vgdb-pipe-to-vgdb-from-3909-by-sn446-on-dragon.ece.drexel.edu ==3909== embedded gdbserver: shared mem /tmp/ vgdb-pipe-shared-mem-vgdb-3909-by-sn446-on-dragon.ece.drexel.edu ==3909== ==3909== TO CONTROL THIS PROCESS USING vgdb (which you probably ==3909== don't want to do, unless you know exactly what you're doing, ==3909== or are doing some strange experiment): ==3909== /usr/local/lib/valgrind/../../bin/vgdb --pid=3909 ...command... ==3909== ==3909== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==3909== /path/to/gdb ./blackscholes ==3909== and then give GDB the following command ==3909== target remote | /usr/local/lib/valgrind/../../bin/vgdb --pid=3909 ==3909== --pid is optional if only one valgrind process is running ==3909== --3909-- Found runtime_resolve (amd64-def): ld-2.5.so+0x11f30=0x3d8fe129a0, length 110 --3909-- Reading syms from /usr/local/lib/valgrind/vgpreload_core-amd64-linux.so (0x4802000) --3909-- Reading syms from /usr/local/lib/valgrind/vgpreload_memcheck-amd64-linux.so (0x4a03000) --3909-- REDIR: 0x3d8fe14550 (index) redirected to 0x4a076f0 (index) --3909-- REDIR: 0x3d8fe14700 (strcmp) redirected to 0x4a07a00 (strcmp) --3909-- Reading syms from /lib64/libm-2.5.so (0x3d90600000) --3909-- Reading syms from /lib64/libc-2.5.so (0x3d90200000) --3909-- REDIR: 0x3d902789f0 (rindex) redirected to 0x4a07540 (rindex) --3909-- Symbol match: found runtime_resolve: ld-2.5.so+0x3d8fe129a0=0x3d8fe129a0 --3909-- REDIR: 0x3d90278600 (strlen) redirected to 0x4a07860 (strlen) PARSEC Benchmark Suite Version 2.1 --3909-- REDIR: 0x3d90273870 (malloc) redirected to 0x4a066ed (malloc) *--3909-- VG_USERREQ__CLIENT_CALL1: func=0x0* *--3909-- REDIR: 0x3d9027a3e0 (mempcpy) redirected to 0x4a08cc0 (mempcpy)* *ERROR: Unable to open file `in_4.txt'.* --3909-- REDIR: 0x3d90271320 (free) redirected to 0x4a062fd (free) ==3909== --3909-- Start dumping at BB 27585 (Prg.Term.)... --3909-- Dump to /home/DREXEL/sn446/projects/accel-metrics-NEW/data/parsec_vgprof/blackscholes/test/callgrind.out.3909 --3909-- Dumping done. ==3909== Events : Ir ==3909== Collected : 137073 ==3909== ==3909== I refs: 137,073 Program exited with code 01. |
|
From: Philippe W. <phi...@sk...> - 2012-08-05 00:15:52
|
On Sat, 2012-08-04 at 18:43 -0400, Siddharth Nilakantan wrote: > When I run it normally, it runs fine as shown above. However, when I > run it under gdb: It is unclear what you are trying to do. Launching gdb on callgrind-amd64-linux means you will debug the callgrind tool. If this is really what you want to do, then see README_DEVELOPERS that describes how to debug Valgrind and its tools. Otherwise, if you want to debug your application while running under callgrind, you can use the embedded Valgrind gdbserver (see the doc, or give --vgdb-error=0 option and follow instructions on the screen). Philippe |
|
From: Siddharth N. <sn...@dr...> - 2012-08-05 01:30:09
|
On 4 August 2012 20:15, Philippe Waroquiers <phi...@sk...>wrote: > On Sat, 2012-08-04 at 18:43 -0400, Siddharth Nilakantan wrote: > > > When I run it normally, it runs fine as shown above. However, when I > > run it under gdb: > > It is unclear what you are trying to do. > > Launching gdb on callgrind-amd64-linux means you will debug > the callgrind tool. > If this is really what you want to do, then see README_DEVELOPERS > that describes how to debug Valgrind and its tools. > > Debugging callgrind is what I wanted to do. I made some modifications to Callgrind for a research project. I was debugging some changes I recently made, when I saw this issue, the first step was to test unmodified source with gdb. Following README_DEVELOPERS, even the pwd example doesn't seem to be working: (gdb) handle SIGSEGV SIGILL nostop noprint Signal Stop Print Pass to program Description SIGILL No No Yes Illegal instruction SIGSEGV No No Yes Segmentation fault (gdb) r pwd Starting program: /usr/local/lib/valgrind/callgrind-amd64-linux pwd warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaaaaaab000 ==10498== Callgrind, a call-graph generating cache profiler ==10498== Copyright (C) 2002-2011, and GNU GPL'd, by Josef Weidendorfer et al. ==10498== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info ==10498== Command: pwd ==10498== ==10498== For interactive control, run 'callgrind_control -h'. --10498-- VG_USERREQ__CLIENT_CALL1: func=0x0 --10498-- VG_USERREQ__CLIENT_CALL1: func=0x0 --10498-- VG_USERREQ__CLIENT_CALL1: func=0x0 ==10498== ==10498== Process terminating with default action of signal 11 (SIGSEGV) ==10498== Access not within mapped region at address 0x0 ==10498== at 0x4A07862: strlen (mc_replace_strmem.c:391) ==10498== by 0x3D9022D7FD: _nl_make_l10nflist (in /lib64/libc-2.5.so) ==10498== by 0x3D902278AA: _nl_find_locale (in /lib64/libc-2.5.so) ==10498== by 0x3D902272CD: setlocale (in /lib64/libc-2.5.so) ==10498== by 0x401756: ??? (in /bin/pwd) ==10498== by 0x3D9021D993: (below main) (in /lib64/libc-2.5.so) ==10498== If you believe this happened as a result of a stack ==10498== overflow in your program's main thread (unlikely but ==10498== possible), you can try to increase the size of the ==10498== main thread stack using the --main-stacksize= flag. ==10498== The main thread stack size used in this run was 10485760. ==10498== ==10498== Events : Ir ==10498== Collected : 114266 ==10498== ==10498== I refs: 114,266 Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. > Otherwise, if you want to debug your application while running > under callgrind, you can use the embedded Valgrind gdbserver > (see the doc, or give --vgdb-error=0 option and follow instructions > on the screen). > > Philippe > > > |
|
From: Philippe W. <phi...@sk...> - 2012-08-05 10:22:32
|
On Sat, 2012-08-04 at 21:29 -0400, Siddharth Nilakantan wrote: > Debugging callgrind is what I wanted to do. I made some modifications > to Callgrind for a research project. > I was debugging some changes I recently made, when I saw this issue, > the first step was to test unmodified source with gdb. > Following README_DEVELOPERS, even the pwd example doesn't seem to be > working: I am using the --wait-for-gdb=yes technique documented in the README_DEVELOPERS (tested on x86), just launching a gdb and attaching to the Valgrind which is in the 'wait for gdb' loop: GNU gdb (GDB) 7.4 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. (gdb) attach 25875 Attaching to process 25875 Reading symbols from /home/philippe/valgrind/trunk_untouched/callgrind/callgrind-x86-linux...done. Failed to read a valid object file image from memory. 0x38025e13 in valgrind_main (argc=0, argv=0x0, envp=0x2) at m_main.c:2017 2017 __asm__ __volatile__("" ::: "memory","cc"); (gdb) break main.c:1829 Breakpoint 1 at 0x380123bc: file main.c, line 1829. (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0x631100a5 in ?? () (gdb) c Continuing. Breakpoint 1, finish () at main.c:1829 1829 CLG_(sprint_eventmapping)(buf, CLG_(dumpmap)); (gdb) bt #0 finish () at main.c:1829 #1 0x38028f5a in shutdown_actions_NORETURN (tid=1, tids_schedretcode=VgSrc_ExitThread) at m_main.c:2448 #2 0x3809d6ca in run_a_thread_NORETURN (tidW=1) at m_syswrap/syswrap-linux.c:199 #3 0x00000000 in ?? () (gdb) |
|
From: Siddharth N. <sn...@dr...> - 2012-08-06 04:59:27
|
I tried this other method and it worked fine. Thanks for the workaround. Exporting the VALGRIND_LAUNCHER variable and directly running gdb on the tool executable seems to cause this problem. And the problem seems to have something to do with redirecting mallocs from the user program in my environment. It didn't seem to happen in my environment the many months prior to this, so I'll have to see what changed recently. Similar issues have been encountered from trying something totally different: http://comments.gmane.org/gmane.comp.debugging.valgrind.devel/16433 On 5 August 2012 06:22, Philippe Waroquiers <phi...@sk...>wrote: > On Sat, 2012-08-04 at 21:29 -0400, Siddharth Nilakantan wrote: > > > > Debugging callgrind is what I wanted to do. I made some modifications > > to Callgrind for a research project. > > I was debugging some changes I recently made, when I saw this issue, > > the first step was to test unmodified source with gdb. > > Following README_DEVELOPERS, even the pwd example doesn't seem to be > > working: > I am using the --wait-for-gdb=yes technique documented in the > README_DEVELOPERS (tested on x86), just launching a gdb and > attaching to the Valgrind which is in the 'wait for gdb' loop: > > GNU gdb (GDB) 7.4 > Copyright (C) 2012 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later < > http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > (gdb) attach 25875 > Attaching to process 25875 > Reading symbols from > /home/philippe/valgrind/trunk_untouched/callgrind/callgrind-x86-linux...done. > Failed to read a valid object file image from memory. > 0x38025e13 in valgrind_main (argc=0, argv=0x0, envp=0x2) at m_main.c:2017 > 2017 __asm__ __volatile__("" ::: "memory","cc"); > (gdb) break main.c:1829 > Breakpoint 1 at 0x380123bc: file main.c, line 1829. > (gdb) c > Continuing. > > Program received signal SIGSEGV, Segmentation fault. > 0x631100a5 in ?? () > (gdb) c > Continuing. > > Breakpoint 1, finish () at main.c:1829 > 1829 CLG_(sprint_eventmapping)(buf, CLG_(dumpmap)); > (gdb) bt > #0 finish () at main.c:1829 > #1 0x38028f5a in shutdown_actions_NORETURN (tid=1, > tids_schedretcode=VgSrc_ExitThread) at m_main.c:2448 > #2 0x3809d6ca in run_a_thread_NORETURN (tidW=1) > at m_syswrap/syswrap-linux.c:199 > #3 0x00000000 in ?? () > (gdb) > > > > |
|
From: Josef W. <Jos...@gm...> - 2012-08-06 12:02:32
|
Am 05.08.2012 00:43, schrieb Siddharth Nilakantan: > When I run it normally, it runs fine as shown above. However, when I run > it under gdb: > $ gdb /usr/local/lib/valgrind/callgrind-amd64-linux > (gdb)*r ./blackscholes 1 in_4.txt prices.txt* You forgot the command line option "--tool=callgrind": (gdb) r --tool=callgrind ./blackscholes ... This is needed to not confuse the function redirection stuff (I think if the --tool option is not given, it partly configures for a memcheck run). Josef |
|
From: Siddharth N. <si...@gm...> - 2012-08-06 17:29:54
|
On 6 August 2012 07:56, Josef Weidendorfer <Jos...@gm...>wrote: > Am 05.08.2012 00:43, schrieb Siddharth Nilakantan: > > When I run it normally, it runs fine as shown above. However, when I run > > it under gdb: > > > $ gdb /usr/local/lib/valgrind/callgrind-amd64-linux > > > (gdb)*r ./blackscholes 1 in_4.txt prices.txt* > > You forgot the command line option "--tool=callgrind": > > (gdb) r --tool=callgrind ./blackscholes ... > > This is needed to not confuse the function redirection stuff > (I think if the --tool option is not given, it partly configures > for a memcheck run). > > I see. I didn't have the latest README_DEVELOPERS from trunk which mentions this. > Josef > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Josef W. <Jos...@gm...> - 2012-08-06 18:03:21
|
Am 06.08.2012 19:29, schrieb Siddharth Nilakantan: > > On 6 August 2012 07:56, Josef Weidendorfer <Jos...@gm... > <mailto:Jos...@gm...>> wrote: > > (gdb) r --tool=callgrind ./blackscholes ... > > This is needed to not confuse the function redirection stuff > (I think if the --tool option is not given, it partly configures > for a memcheck run). > > I see. I didn't have the latest README_DEVELOPERS from trunk which > mentions this. Sorry. When answering, I thought it was mentioned in README_DEVELOPERS. But it wasn't. So I added it today ;-) May I ask if it actually helped for you? Josef |
|
From: Siddharth N. <si...@gm...> - 2012-08-06 20:23:42
|
On 6 August 2012 14:03, Josef Weidendorfer <Jos...@gm...>wrote: > Am 06.08.2012 19:29, schrieb Siddharth Nilakantan: > >> >> On 6 August 2012 07:56, Josef Weidendorfer <Jos...@gm... >> <mailto:Josef.Weidendorfer@**gmx.de <Jos...@gm...>>> wrote: >> > > > >> (gdb) r --tool=callgrind ./blackscholes ... >> >> This is needed to not confuse the function redirection stuff >> (I think if the --tool option is not given, it partly configures >> for a memcheck run). >> >> I see. I didn't have the latest README_DEVELOPERS from trunk which >> mentions this. >> > > Sorry. > When answering, I thought it was mentioned in README_DEVELOPERS. > But it wasn't. So I added it today ;-) > > May I ask if it actually helped for you? > > Yes, thanks. However, there are some occasions when it segfaults early and I just (gdb) continue which works. The segfault goes away with "handle SIGSEGV SIGILL nostop noprint" > Josef > |