|
From: Bart V. A. <bar...@gm...> - 2008-04-03 18:38:34
|
Hello,
Sometimes when Valgrind prints a stack trace on an AMD64 system, there
are a few dummy frames at the top which do not make sense. Apparently
sometimes Valgrind tries to go up "too high" on the stack. The patch
below should improve stack examination by Valgrind with only a minimal
performance impact. All it does is to check that the instruction
pointer fetched from the stack is not null and that what is assumed to
be an instruction pointer does not point to the stack being examined.
Any comments are welcome.
Bart.
svn diff coregrind/m_stacktrace.c
Index: coregrind/m_stacktrace.c
===================================================================
--- coregrind/m_stacktrace.c (revision 7839)
+++ coregrind/m_stacktrace.c (working copy)
@@ -276,8 +276,10 @@
address; instead scan a likely section of stack (eg sp .. sp+256)
and use suitable values found there.
*/
- if (fp_min <= sp && sp < fp_max) {
- ip = ((UWord*)sp)[0];
+ if (fp_min <= sp && sp < fp_max
+ && (ip = ((UWord*)sp)[0]) != 0
+ && (ip < fp_min || ip >= fp_max))
+ {
if (sps) sps[i] = sp;
if (fps) fps[i] = fp;
ips[i++] = ip;
|
|
From: Julian S. <js...@ac...> - 2008-04-05 11:25:03
|
Could you please send an example of a stack trace with extra frames in,
to look at?
J
On Thursday 03 April 2008 20:38, Bart Van Assche wrote:
> Hello,
>
> Sometimes when Valgrind prints a stack trace on an AMD64 system, there
> are a few dummy frames at the top which do not make sense. Apparently
> sometimes Valgrind tries to go up "too high" on the stack. The patch
> below should improve stack examination by Valgrind with only a minimal
> performance impact. All it does is to check that the instruction
> pointer fetched from the stack is not null and that what is assumed to
> be an instruction pointer does not point to the stack being examined.
>
> Any comments are welcome.
>
> Bart.
>
> svn diff coregrind/m_stacktrace.c
> Index: coregrind/m_stacktrace.c
> ===================================================================
> --- coregrind/m_stacktrace.c (revision 7839)
> +++ coregrind/m_stacktrace.c (working copy)
> @@ -276,8 +276,10 @@
> address; instead scan a likely section of stack (eg sp ..
> sp+256) and use suitable values found there.
> */
> - if (fp_min <= sp && sp < fp_max) {
> - ip = ((UWord*)sp)[0];
> + if (fp_min <= sp && sp < fp_max
> + && (ip = ((UWord*)sp)[0]) != 0
> + && (ip < fp_min || ip >= fp_max))
> + {
> if (sps) sps[i] = sp;
> if (fps) fps[i] = fp;
> ips[i++] = ip;
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplac
>e _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Bart V. A. <bar...@gm...> - 2008-04-05 15:48:01
|
> On Thursday 03 April 2008 20:38, Bart Van Assche wrote:
> > Sometimes when Valgrind prints a stack trace on an AMD64 system, there
> > are a few dummy frames at the top which do not make sense. Apparently
> > sometimes Valgrind tries to go up "too high" on the stack. The patch
> > below should improve stack examination by Valgrind with only a minimal
> > performance impact. All it does is to check that the instruction
> > pointer fetched from the stack is not null and that what is assumed to
> > be an instruction pointer does not point to the stack being examined.
> >
> > Any comments are welcome.
> >
> > Bart.
> >
> > svn diff coregrind/m_stacktrace.c
> > Index: coregrind/m_stacktrace.c
> > ===================================================================
> > --- coregrind/m_stacktrace.c (revision 7839)
> > +++ coregrind/m_stacktrace.c (working copy)
> > @@ -276,8 +276,10 @@
> > address; instead scan a likely section of stack (eg sp ..
> > sp+256) and use suitable values found there.
> > */
> > - if (fp_min <= sp && sp < fp_max) {
> > - ip = ((UWord*)sp)[0];
> > + if (fp_min <= sp && sp < fp_max
> > + && (ip = ((UWord*)sp)[0]) != 0
> > + && (ip < fp_min || ip >= fp_max))
> > + {
> > if (sps) sps[i] = sp;
> > if (fps) fps[i] = fp;
> > ips[i++] = ip;
> >
On Sat, Apr 5, 2008 at 1:20 PM, Julian Seward <js...@ac...> wrote:
>
> Could you please send an example of a stack trace with extra frames in,
> to look at?
Sure. When I call VG_(get_StackTrace)() shortly after a client thread
has been created (e.g. from drd_clientreq.c just before
VG_USERREQ__DRD_SUPPRESS_CURRENT_STACK), I get the following results:
Before applying the patch:
--2445-- thread 1/1
--2445-- [ 0] 0x004c26a32 0x7fefffbc0 0x7fefffce0
--2445-- [ 1] 0x00400cc56 0x7fefffcf0 0x00401c000
--2445-- [ 2] 0x00400cd7e 0x7fefffd30 0x00401c000
--2445-- [ 3] 0x004000aaa 0x7fefffd90 0x000000000
--2445-- [ 4] 0x000000001 0x7fefffd90 0x000000000
--2445-- [ 5] 0x7ff00018b 0x7fefffd98 0x000000000
--2445-- [ 6] 0x000000000 0x7fefffda0 0x000000000
--2445-- [ 7] 0x7ff0001a1 0x7fefffda8 0x000000000
--2445-- [ 8] 0x7ff0001c0 0x7fefffdb0 0x000000000
--2445-- [ 9] 0x7ff0001d9 0x7fefffdb8 0x000000000
--2445-- [10] 0x7ff0001f2 0x7fefffdc0 0x000000000
--2445-- [11] 0x7ff000202 0x7fefffdc8 0x000000000
--2445-- [12] 0x7ff000219 0x7fefffdd0 0x000000000
--2445-- [13] 0x7ff00024b 0x7fefffdd8 0x000000000
--2445-- [14] 0x7ff00025e 0x7fefffde0 0x000000000
--2445-- [15] 0x7ff000272 0x7fefffde8 0x000000000
--2445-- [16] 0x7ff00028d 0x7fefffdf0 0x000000000
--2445-- [17] 0x7ff00029c 0x7fefffdf8 0x000000000
--2445-- [18] 0x7ff0002bf 0x7fefffe00 0x000000000
--2445-- [19] 0x7ff0002f1 0x7fefffe08 0x000000000
--2445-- thread 2/2
--2445-- [ 0] 0x004c26884 0x005b8a0d0 0x005b8a130
--2445-- [ 1] 0x004e30020 0x005b8a140 0x000000000
--2445-- [ 2] 0x005109f8d 0x005b8a260 0x000000000
--2445-- [ 3] 0x000000000 0x005b8a260 0x000000000
--2445-- [ 4] 0x000000000 0x005b8a268 0x000000000
--2445-- [ 5] 0x000000000 0x005b8a270 0x000000000
--2445-- [ 6] 0x000000000 0x005b8a278 0x000000000
--2445-- [ 7] 0x000000000 0x005b8a280 0x000000000
--2445-- [ 8] 0x000000000 0x005b8a288 0x000000000
--2445-- [ 9] 0x000000000 0x005b8a290 0x000000000
--2445-- [10] 0x000000000 0x005b8a298 0x000000000
--2445-- [11] 0x000000000 0x005b8a2a0 0x000000000
--2445-- [12] 0x000000000 0x005b8a2a8 0x000000000
--2445-- [13] 0x000000000 0x005b8a2b0 0x000000000
--2445-- [14] 0x000000000 0x005b8a2b8 0x000000000
--2445-- [15] 0x000000000 0x005b8a2c0 0x000000000
--2445-- [16] 0x000000000 0x005b8a2c8 0x000000000
--2445-- [17] 0x000000000 0x005b8a2d0 0x000000000
--2445-- [18] 0x000000000 0x005b8a2d8 0x000000000
--2445-- [19] 0x000000000 0x005b8a2e0 0x000000000
After having applied the patch:
--1280-- thread 1/1
--1280-- [ 0] 0x004c26a32 0x7fefffbc0 0x7fefffce0
--1280-- [ 1] 0x00400cc56 0x7fefffcf0 0x00401c000
--1280-- [ 2] 0x00400cd7e 0x7fefffd30 0x00401c000
--1280-- [ 3] 0x004000aaa 0x7fefffd90 0x000000000
--1280-- [ 4] 0x000000001 0x7fefffd90 0x000000000
--1280-- thread 2/2
--1280-- [ 0] 0x004c26884 0x005b8a0d0 0x005b8a130
--1280-- [ 1] 0x004e30020 0x005b8a140 0x000000000
--1280-- [ 2] 0x005109f8d 0x005b8a260 0x000000000
Bart.
|
|
From: Julian S. <js...@ac...> - 2008-04-06 17:25:36
|
Could you instead try stopping the unwind when fp == 0, and no other changes? As per the AMD64 ABI Draft 0.98 page 28, %rbp should be zero for the deepest frame in the stack. J |
|
From: Bart V. A. <bar...@gm...> - 2008-04-07 16:46:10
|
On Sun, Apr 6, 2008 at 7:21 PM, Julian Seward <js...@ac...> wrote:
>
> Could you instead try stopping the unwind when fp == 0, and no
> other changes? As per the AMD64 ABI Draft 0.98 page 28, %rbp
> should be zero for the deepest frame in the stack.
I tried the patch below, but unfortunately it causes
helgrind/tests/hg05_race2 and exp-drd/tests/hg05_race2 to fail. Is the
patch below a correct implementation of the ABI specs ?
Bart.
Index: coregrind/m_stacktrace.c
===================================================================
--- coregrind/m_stacktrace.c (revision 7858)
+++ coregrind/m_stacktrace.c (working copy)
@@ -285,7 +285,9 @@
VG_(printf)(" ipsH[%d]=%08p\n", i-1, ips[i-1]);
ip = ip - 1;
sp += 8;
- continue;
+ if (fp) {
+ continue;
+ }
}
/* No luck at all. We have to give up. */
|
|
From: Julian S. <js...@ac...> - 2008-04-09 20:02:02
|
> I tried the patch below, but unfortunately it causes > helgrind/tests/hg05_race2 and exp-drd/tests/hg05_race2 to fail. Is the > patch below a correct implementation of the ABI specs ? The ABI merely says that the stack ends when fp == 0. So I would have put "if (fp == 0) break;" at the start of the unwind loop. I'm sorry to be slow on this. I'll try to look at it again early next week. J |
|
From: Julian S. <js...@ac...> - 2008-04-15 20:24:54
|
> Sure. When I call VG_(get_StackTrace)() shortly after a client thread > has been created (e.g. from drd_clientreq.c just before > VG_USERREQ__DRD_SUPPRESS_CURRENT_STACK), I get the following results: > > Before applying the patch: > > --2445-- thread 1/1 > --2445-- [ 0] 0x004c26a32 0x7fefffbc0 0x7fefffce0 > --2445-- [ 1] 0x00400cc56 0x7fefffcf0 0x00401c000 > --2445-- [ 2] 0x00400cd7e 0x7fefffd30 0x00401c000 > --2445-- [ 3] 0x004000aaa 0x7fefffd90 0x000000000 > --2445-- [ 4] 0x000000001 0x7fefffd90 0x000000000 > --2445-- [ 5] 0x7ff00018b 0x7fefffd98 0x000000000 > --2445-- [ 6] 0x000000000 0x7fefffda0 0x000000000 > --2445-- [ 7] 0x7ff0001a1 0x7fefffda8 0x000000000 > --2445-- [ 8] 0x7ff0001c0 0x7fefffdb0 0x000000000 > --2445-- [ 9] 0x7ff0001d9 0x7fefffdb8 0x000000000 > --2445-- [10] 0x7ff0001f2 0x7fefffdc0 0x000000000 > --2445-- [11] 0x7ff000202 0x7fefffdc8 0x000000000 > --2445-- [12] 0x7ff000219 0x7fefffdd0 0x000000000 > --2445-- [13] 0x7ff00024b 0x7fefffdd8 0x000000000 > --2445-- [14] 0x7ff00025e 0x7fefffde0 0x000000000 > --2445-- [15] 0x7ff000272 0x7fefffde8 0x000000000 > --2445-- [16] 0x7ff00028d 0x7fefffdf0 0x000000000 > --2445-- [17] 0x7ff00029c 0x7fefffdf8 0x000000000 > --2445-- [18] 0x7ff0002bf 0x7fefffe00 0x000000000 > --2445-- [19] 0x7ff0002f1 0x7fefffe08 0x000000000 Can you send a version of this as printed out in the normal way (with symbol names etc), so we can see what in fact all this stuff on the stack really is? J |
|
From: Bart V. A. <bar...@gm...> - 2008-04-16 18:15:30
|
On Tue, Apr 15, 2008 at 10:20 PM, Julian Seward <js...@ac...> wrote: > > Can you send a version of this as printed out in the normal way > (with symbol names etc), so we can see what in fact all this > stuff on the stack really is? This is what I get when I add the output of VG_(describe_IP)(): thread 1/1 [ 0] sp 0x7fefffb90 fp 0x7fefffcb0 ip 0x4C26C82: init (drd_pthread_intercepts.c:242) [ 1] sp 0x7fefffcc0 fp 0x7fefffcd0 ip 0x4C272E2: (within /home/bart/software/valgrind-inner/exp-drd/vgpreload_exp-drd-amd64-linux.so) [ 2] sp 0x7fefffce0 fp 0x00401c000 ip 0x4C2159B: (within /home/bart/software/valgrind-inner/exp-drd/vgpreload_exp-drd-amd64-linux.so) [ 3] sp 0x7fefffce0 fp 0x00401c000 ip 0x4047000: ??? [ 4] sp 0x7fefffce8 fp 0x00401c000 ip 0x400CC56: (within /lib64/ld-2.6.1.so) [ 5] sp 0x7fefffd30 fp 0x00401c000 ip 0x400CD7E: (within /lib64/ld-2.6.1.so) [ 6] sp 0x7fefffd90 fp 0x000000000 ip 0x4000AAA: (within /lib64/ld-2.6.1.so) [ 7] sp 0x7fefffd90 fp 0x000000000 ip 0x2: ??? [ 8] sp 0x7fefffd98 fp 0x000000000 ip 0x7FF000187: ??? [ 9] sp 0x7fefffda0 fp 0x000000000 ip 0x7FF00019D: ??? [10] sp 0x7fefffda8 fp 0x000000000 ip 0x0: ??? [11] sp 0x7fefffdb0 fp 0x000000000 ip 0x7FF0001A0: ??? [12] sp 0x7fefffdb8 fp 0x000000000 ip 0x7FF0001BF: ??? [13] sp 0x7fefffdc0 fp 0x000000000 ip 0x7FF0001D8: ??? [14] sp 0x7fefffdc8 fp 0x000000000 ip 0x7FF0001F1: ??? [15] sp 0x7fefffdd0 fp 0x000000000 ip 0x7FF000201: ??? [16] sp 0x7fefffdd8 fp 0x000000000 ip 0x7FF000218: ??? [17] sp 0x7fefffde0 fp 0x000000000 ip 0x7FF00024A: ??? [18] sp 0x7fefffde8 fp 0x000000000 ip 0x7FF00025D: ??? [19] sp 0x7fefffdf0 fp 0x000000000 ip 0x7FF000271: ??? thread 2/2 [ 0] sp 0x005b8a0d0 fp 0x005b8a130 ip 0x4C26AD4: vg_thread_wrapper (drd_pthread_intercepts.c:164) [ 1] sp 0x005b8a140 fp 0x000000000 ip 0x4E30020: start_thread (in /lib64/libpthread-2.6.1.so) [ 2] sp 0x005b8a260 fp 0x000000000 ip 0x5109F8D: clone (in /lib64/libc-2.6.1.so) [ 3] sp 0x005b8a260 fp 0x000000000 ip 0x0: ??? [ 4] sp 0x005b8a268 fp 0x000000000 ip 0x0: ??? [ 5] sp 0x005b8a270 fp 0x000000000 ip 0x0: ??? [ 6] sp 0x005b8a278 fp 0x000000000 ip 0x0: ??? [ 7] sp 0x005b8a280 fp 0x000000000 ip 0x0: ??? [ 8] sp 0x005b8a288 fp 0x000000000 ip 0x0: ??? [ 9] sp 0x005b8a290 fp 0x000000000 ip 0x0: ??? [10] sp 0x005b8a298 fp 0x000000000 ip 0x0: ??? [11] sp 0x005b8a2a0 fp 0x000000000 ip 0x0: ??? [12] sp 0x005b8a2a8 fp 0x000000000 ip 0x0: ??? [13] sp 0x005b8a2b0 fp 0x000000000 ip 0x0: ??? [14] sp 0x005b8a2b8 fp 0x000000000 ip 0x0: ??? [15] sp 0x005b8a2c0 fp 0x000000000 ip 0x0: ??? [16] sp 0x005b8a2c8 fp 0x000000000 ip 0x0: ??? [17] sp 0x005b8a2d0 fp 0x000000000 ip 0x0: ??? [18] sp 0x005b8a2d8 fp 0x000000000 ip 0x0: ??? [19] sp 0x005b8a2e0 fp 0x000000000 ip 0x0: ??? Bart. |