|
From: Julian S. <js...@ac...> - 2008-03-02 23:54:38
|
Greetings all. I intend to merge the DATASYMS branch to trunk shortly. This branch adds the ability to read Dwarf3 type and variable information, and to use that to generate better descriptions of data addresses on thread stacks and in global variables. It also is potentially useful for tools which require descriptions of stack- and global-variables at instrumentation time. Here are a couple of examples of the output it can produce: Location 0x60103e is 0 bytes inside nonstatic_global_def[2], a global variable declared at varinfo3.c:36 Location 0x7feffba09 is 1 byte inside a[3].xyzzy[21].c2[2], declared at varinfo4.c:45, in frame #1 of thread 1 These descriptions are created by reading Dwarf3 .debug_info section, and associated other sections. This branch also fixes reading of ELF data symbols. So, even if Dwarf3 information for global variables is absent or unreadable for whatever reason, at least the size and address of them is still available. I have modified Memcheck and Helgrind to use this new info. The modifications are trivial, since it merely requires calling the new functions VG_(get_data_description) and/or VG_(get_datasym_and_offset) to get the relevant info. The downside is that reading Dwarf3 is expensive in both time and memory. Despite considerable efforts at tuning, reading this stuff basically doubles the startup time of (eg) konqueror on Memcheck, if not worse, and adds a couple of hundred megabytes to the process size. Consequently, only text- and data-symbol reading are enabled by default. Tools that want Dwarf3 info must ask for it via the "var_info" "need" in the core/tool iface (include/pub_tool_iface.h). Only Helgrind and DRD make this request at present. Memcheck is able to make use of Dwarf3 info if it has been read, but does not read it by default. To allow users to force this information to be read, a flag --read-var-info=yes has been added. This is a core flag and so applies to all tools. The changes are fairly self contained and exist almost entirely within m_debuginfo. From outside the visible changes are: * The type "SegInfo" has been renamed to "DebugInfo", which is more accurate. * VG_(needs_data_syms) has been removed -- data sym reading is now always done * VG_(needs_var_info) has been added * VG_(get_datasym_and_offset) and VG_(get_data_description) have been added. This is a bit of a stupid interface and I might combine the two after the merge. * A new flag --read-var-info=no|yes [no] has been added * VG_(seginfo_sect_kind) should now work reliably -- it never really did before now. As part of this, the machinery for reading ELF symbol tables was majorly overhauled and is now more picky than it was before. I think I have it working reliably again, but there may still be bugs in it. Because the changes are mostly self contained, I don't expect this merge to cause any serious problems. Please complain if they do. J |
|
From: Nicholas N. <nj...@cs...> - 2008-03-03 03:17:21
|
On Mon, 3 Mar 2008, Julian Seward wrote: > Location 0x7feffba09 is 1 byte inside a[3].xyzzy[21].c2[2], > declared at varinfo4.c:45, in frame #1 of thread 1 What's the frame number? The rest sounds good to me. N |
|
From: Julian S. <js...@ac...> - 2008-03-03 03:20:42
|
On Monday 03 March 2008 04:17, Nicholas Nethercote wrote: > On Mon, 3 Mar 2008, Julian Seward wrote: > > Location 0x7feffba09 is 1 byte inside a[3].xyzzy[21].c2[2], > > declared at varinfo4.c:45, in frame #1 of thread 1 > > What's the frame number? It tries to locate an address in all call frames of all thread stacks. So "frame #1" is really a cryptic way to say "1 frame down from the top of stack of thread 1". I found it hard to think of an equally concise but less cryptic way to phrase it. J |
|
From: Nicholas N. <nj...@cs...> - 2008-03-03 03:49:14
|
On Mon, 3 Mar 2008, Julian Seward wrote: > On Monday 03 March 2008 04:17, Nicholas Nethercote wrote: >> On Mon, 3 Mar 2008, Julian Seward wrote: >>> Location 0x7feffba09 is 1 byte inside a[3].xyzzy[21].c2[2], >>> declared at varinfo4.c:45, in frame #1 of thread 1 >> >> What's the frame number? > > It tries to locate an address in all call frames of all thread > stacks. So "frame #1" is really a cryptic way to say "1 frame > down from the top of stack of thread 1". I found it hard to > think of an equally concise but less cryptic way to phrase it. So it's the top stack frame on thread 1's stack? Or the 2nd frame? Can you summarise the different messages that are possible now -- eg. stack variables, static (global) variables, static (local) variables, heap variables, etc? That might help determine if the messages could be made clearer. Nick |
|
From: Tom H. <to...@co...> - 2008-03-03 11:01:25
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> Memcheck is able to make use of Dwarf3 info if it has been read,
> but does not read it by default. To allow users to force this
> information to be read, a flag --read-var-info=yes has been
> added. This is a core flag and so applies to all tools.
I'm getting thousands of messages along these lines when I turn
on reading of variable info:
--29598-- warning: addVar: in range 0xFA08 .. 0xFA12 outside segment 0x36DD005210 .. 0x36DD00FC07 (ignore)
It looks like they all relate to the C library rather than our
code.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2008-03-03 11:12:53
|
> --29598-- warning: addVar: in range 0xFA08 .. 0xFA12 outside segment > 0x36DD005210 .. 0x36DD00FC07 (ignore) And just when I thought I had it all working :-) Looks like a failure to add on the text bias at some point. Can you send me the relevant .so to look at? J |
|
From: Julian S. <js...@ac...> - 2008-03-07 22:31:28
|
On Monday 03 March 2008 12:01, Tom Hughes wrote: > I'm getting thousands of messages along these lines when I turn > on reading of variable info: > > --29598-- warning: addVar: in range 0xFA08 .. 0xFA12 outside segment > 0x36DD005210 .. 0x36DD00FC07 (ignore) (Background, for the benefit of the archive: the problem occurs when an object is first split into a base object (without Dwarf3 info) and a debuginfo object (with Dwarf3 info), and then the base object is prelinked to some nonzero address, but the debuginfo object is left unchanged.) Well, I have tried to fix this (r7590) but I'd by lying to claim the fix is anything other than an unprincipled kludge, and I can't say I'm happy with the outcome. At least it no longer complains for the test case you sent. But whether it really computes the correct text and data avmas for the affected objects is open to doubt. Is there a way you can test this? I think an adequate test would be to force memcheck to attempt description of an address obtained as follows (force it to describe by free()ing the addr): * a stack-local variable in a thusly-afflicted (debuginfo-split and then prelinked) object * a global var in ditto J |
|
From: Bart V. A. <bar...@gm...> - 2008-03-03 19:33:34
|
On Mon, Mar 3, 2008 at 12:51 AM, Julian Seward <js...@ac...> wrote: > Because the changes are mostly self contained, I don't expect > this merge to cause any serious problems. Please complain if > they do. The following command triggers a segmentation fault on my system: ./vg-in-place --tool=exp-drd --trace-address=0x601088 --trace-danger-set=yes exp-drd/tests/hg01_all_ok When I start the above command under gdb, then gdb tells me that the segmentation fault happened at line 253 in m_stacktrace.c, and that fp_min == 0. Who should look into this ? Program received signal SIGSEGV, Segmentation fault. vgPlain_get_StackTrace_wrk (tid_if_known=<value optimized out>, ips=<value optimized out>, n_ips=12, sps=0x0, fps=0x0, ip=0, sp=0, fp=0, lr=0, fp_min=0, fp_max_orig=0) at m_stacktrace.c:253 253 ip = (((UWord*)fp)[1]); (gdb) print fp $1 = 0 (gdb) where #0 vgPlain_get_StackTrace_wrk (tid_if_known=<value optimized out>, ips=<value optimized out>, n_ips=12, sps=0x0, fps=0x0, ip=0, sp=0, fp=0, lr=0, fp_min=0, fp_max_orig=0) at m_stacktrace.c:253 #1 0x000000003801d504 in vgPlain_get_StackTrace (tid=1, ips=0x3892c7d0, n_ips=12, sps=0x0, fps=0x0, first_ip_delta=0) at m_stacktrace.c:477 #2 0x000000003801d56a in vgPlain_get_and_pp_StackTrace (tid=10, n_ips=949143368) at m_stacktrace.c:520 #3 0x0000000038012eb1 in valgrind_main (argc=<value optimized out>, argv=<value optimized out>, envp=0x7ffffa7794a8) at m_main.c:1789 #4 0x00000000380149fe in _start_in_C_linux (pArgc=0x7ffffa779470) at m_main.c:2375 #5 0x0000000038011891 in _start () (gdb) print fp_min $2 = 0 |
|
From: Julian S. <js...@ac...> - 2008-03-03 22:21:20
|
Fixed (r7551). J On Monday 03 March 2008 20:33, Bart Van Assche wrote: > On Mon, Mar 3, 2008 at 12:51 AM, Julian Seward <js...@ac...> wrote: > > Because the changes are mostly self contained, I don't expect > > this merge to cause any serious problems. Please complain if > > they do. > > The following command triggers a segmentation fault on my system: > > ./vg-in-place --tool=exp-drd --trace-address=0x601088 > --trace-danger-set=yes exp-drd/tests/hg01_all_ok > > When I start the above command under gdb, then gdb tells me that the > segmentation fault happened at line 253 in m_stacktrace.c, and that > fp_min == 0. Who should look into this ? > > Program received signal SIGSEGV, Segmentation fault. > vgPlain_get_StackTrace_wrk (tid_if_known=<value optimized out>, > ips=<value optimized out>, n_ips=12, sps=0x0, fps=0x0, ip=0, sp=0, > fp=0, lr=0, fp_min=0, fp_max_orig=0) at m_stacktrace.c:253 > 253 ip = (((UWord*)fp)[1]); > (gdb) print fp > $1 = 0 > (gdb) where > #0 vgPlain_get_StackTrace_wrk (tid_if_known=<value optimized out>, > ips=<value optimized out>, n_ips=12, sps=0x0, fps=0x0, ip=0, sp=0, > fp=0, lr=0, fp_min=0, fp_max_orig=0) at m_stacktrace.c:253 > #1 0x000000003801d504 in vgPlain_get_StackTrace (tid=1, > ips=0x3892c7d0, n_ips=12, sps=0x0, fps=0x0, first_ip_delta=0) at > m_stacktrace.c:477 > #2 0x000000003801d56a in vgPlain_get_and_pp_StackTrace (tid=10, > n_ips=949143368) at m_stacktrace.c:520 > #3 0x0000000038012eb1 in valgrind_main (argc=<value optimized out>, > argv=<value optimized out>, envp=0x7ffffa7794a8) at m_main.c:1789 > #4 0x00000000380149fe in _start_in_C_linux (pArgc=0x7ffffa779470) at > m_main.c:2375 > #5 0x0000000038011891 in _start () > (gdb) print fp_min > $2 = 0 > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Josef W. <Jos...@gm...> - 2008-03-04 14:01:16
|
On Monday 03 March 2008, Julian Seward wrote: > I intend to merge the DATASYMS branch to trunk shortly. Hi Julian, some time ago there was the wish for a call tree trace similar to strace/ltrace via valgrind. Can your machinary help to add parameter name/type information the such a call tree trace? I assume one has to check the number of parameters, their type, and extract the values from the stack when entering functions. Is it easy to get at this information now? Josef |
|
From: Bart V. A. <bar...@gm...> - 2008-03-12 07:18:25
|
On Mon, Mar 3, 2008 at 12:51 AM, Julian Seward <js...@ac...> wrote: > > I intend to merge the DATASYMS branch to trunk shortly. Hello Julian, When I run Valgrind with option -v on an Ubuntu 7.10 (i386) system, Valgrind complains about CRC mismatches in the debug info. Is this an Ubuntu bug ? $ ./vg-in-place -v --tool=none none/tests/pth_empty ... --13503-- Reading syms from /lib/ld-2.6.1.so (0x4000000) --13503-- Reading debug info from /lib/ld-2.6.1.so .. --13503-- .. CRC mismatch (computed b27da0e3 wanted c257421f) --13503-- object doesn't have a symbol table ... Bart. |
|
From: Julian S. <js...@ac...> - 2008-03-13 11:50:05
|
> When I run Valgrind with option -v on an Ubuntu 7.10 (i386) system, > Valgrind complains about CRC mismatches in the debug info. Is this an > Ubuntu bug ? > > $ ./vg-in-place -v --tool=none none/tests/pth_empty > ... > --13503-- Reading syms from /lib/ld-2.6.1.so (0x4000000) > --13503-- Reading debug info from /lib/ld-2.6.1.so .. > --13503-- .. CRC mismatch (computed b27da0e3 wanted c257421f) > --13503-- object doesn't have a symbol table Hmm, it's strange that it believes /lib/ld-2.6.1.so to be both the base object and the debuginfo file. Can you send me your /lib/ld-2.6.1.so for investigation? J |
|
From: Bart V. A. <bar...@gm...> - 2008-03-13 19:46:46
|
On Thu, Mar 13, 2008 at 12:46 PM, Julian Seward <js...@ac...> wrote: > > > When I run Valgrind with option -v on an Ubuntu 7.10 (i386) system, > > Valgrind complains about CRC mismatches in the debug info. Is this an > > Ubuntu bug ? > > > > $ ./vg-in-place -v --tool=none none/tests/pth_empty > > ... > > --13503-- Reading syms from /lib/ld-2.6.1.so (0x4000000) > > --13503-- Reading debug info from /lib/ld-2.6.1.so .. > > --13503-- .. CRC mismatch (computed b27da0e3 wanted c257421f) > > --13503-- object doesn't have a symbol table > > Hmm, it's strange that it believes /lib/ld-2.6.1.so to be both > the base object and the debuginfo file. Can you send me your > /lib/ld-2.6.1.so for investigation? I just sent this file to you by e-mail. Bart. |
|
From: Bart V. A. <bar...@gm...> - 2008-03-26 17:52:55
|
On Mon, Mar 3, 2008 at 12:51 AM, Julian Seward <js...@ac...> wrote: > > * VG_(needs_var_info) has been added Hello Julian, Although I still consider it as a great feature that it is now possible in Valgrind tools to obtain detailed information about variables, I will disable this by default in exp-drd. The problem is that reading all the variable info at once in memory takes up a lot of space. E.g. for Firefox 3 more than 2 GB is needed to read in all variables. My PC does not have so much memory. After having commented out the VG_(needs_var_info)() call in exp-drd, I can run Firefox 3 under exp-drd. Bart. |
|
From: Nicholas N. <nj...@cs...> - 2008-03-26 21:38:43
|
On Wed, 26 Mar 2008, Bart Van Assche wrote: > After having commented out the VG_(needs_var_info)() call in exp-drd, > I can run Firefox 3 under exp-drd. Is there much scope for compacting the var info, Julian? N |
|
From: Julian S. <js...@ac...> - 2008-03-27 15:20:17
|
> Although I still consider it as a great feature that it is now
> possible in Valgrind tools to obtain detailed information about
> variables, I will disable this by default in exp-drd. The problem is
> that reading all the variable info at once in memory takes up a lot of
> space. E.g. for Firefox 3 more than 2 GB is needed to read in all
> variables. My PC does not have so much memory.
Yes. I know the problem. I think I was a bit naive in assuming
that the space requirements wouldn't be a problem.
Did you configure firefox like this?
./configure --prefix=$XYZZYFOOBAR --enable-application=browser \
--enable-optimize="-O -g"
so that you are building at -O1 instead of -O0 ? It reduces
the amount of generated code a lot and so might reduce the amount
of debug info too. My experience with firefox is that the
variable info takes "only" about 500MB.
Alternative you could just add more swap space. After all that
variable info is read in and mostly ignored, so it's OK for the
process size to get very large if half of it can be swapped out
and is never referenced again.
J
|
|
From: <bar...@gm...> - 2008-03-28 18:58:07
|
On 3/27/08, Julian Seward <js...@ac...> wrote: > Did you configure firefox like this? > > ./configure --prefix=$XYZZYFOOBAR --enable-application=browser \ > --enable-optimize="-O -g" > > so that you are building at -O1 instead of -O0 ? It reduces > the amount of generated code a lot and so might reduce the amount > of debug info too. My experience with firefox is that the > variable info takes "only" about 500MB. > > Alternative you could just add more swap space. After all that > variable info is read in and mostly ignored, so it's OK for the > process size to get very large if half of it can be swapped out > and is never referenced again. Thanks for the hint. Adding -O1 helped but, sorry, not enough. Virtual memory usage of exp-drd is now about 2.2 GB just after having read variable info -- this is still too much. And yes, I can increase the available virtual memory on my PC, but I can't ask this to all exp-drd users. By the way, do you know how gdb handles variable info ? Does it read all variable info at once or does it read this information only when needed ? Bart. |
|
From: Doug E. <dj...@go...> - 2008-04-17 23:14:04
|
On Fri, Mar 28, 2008 at 11:58 AM, <bar...@gm...> wrote: > By the way, do you know how gdb handles variable info ? Does it read > all variable info at once or does it read this information only when > needed ? GDB reads the info lazily. The granularity (basically) is at the object file level. |