|
From: <sv...@va...> - 2009-07-29 10:57:21
|
Author: sewardj
Date: 2009-07-29 11:57:09 +0100 (Wed, 29 Jul 2009)
New Revision: 10655
Log:
Note results of investigation into segfaulting of tc22 on H on MacOS.
Modified:
trunk/helgrind/tests/Makefile.am
Modified: trunk/helgrind/tests/Makefile.am
===================================================================
--- trunk/helgrind/tests/Makefile.am 2009-07-29 07:00:01 UTC (rev 10654)
+++ trunk/helgrind/tests/Makefile.am 2009-07-29 10:57:09 UTC (rev 10655)
@@ -99,6 +99,23 @@
tc24_nonzero_sem
# DDD: it seg faults, and then the Valgrind exit path hangs
+# JRS 29 July 09: it craps out in the stack unwinder, in
+#==13480== at 0xF00B81FF: ??? f00b8180 VG_(get_StackTrace_wrk)
+#==13480== by 0xF00B83F8: ??? f00b8340 VG_(get_StackTrace)
+#==13480== by 0xF009FE19: ??? f009fd70 record_ExeContext_wrk
+#==13480== by 0xF009D92E: ??? f009d8c0 construct_error
+#==13480== by 0xF009F001: ??? f009eef0 VG_(maybe_record_error)
+#==13480== by 0xF0081F80: ??? f0081f00 HG_(record_error_misc)
+#==13480== by 0xF0089C00: ??? f0089b80 evh__pre_thread_ll_exit
+#==13480== by 0xF01111D1: ??? f0111070 run_a_thread_NORETURN
+#==13480== by 0xF0111512: ??? f0111500 start_thread_NORETURN
+# when the thread being unwound is at __bsdthread_terminate+0
+#
+# Like Tom says, the stack unwinder protection is bollocks.
+# We should junk all previous schemes and simply get the
+# stack unwinder to consult aspacem at each frame (cache-accelerated,
+# of course) to check each page it visits is accessible.
+#
if ! VGCONF_PLATFORMS_INCLUDE_X86_DARWIN
check_PROGRAMS += \
tc22_exit_w_lock
|
|
From: Tom H. <to...@co...> - 2009-07-29 11:14:33
Attachments:
valgrind-isreadable.patch
|
On 29/07/09 11:57, sv...@va... wrote: > +# Like Tom says, the stack unwinder protection is bollocks. > +# We should junk all previous schemes and simply get the > +# stack unwinder to consult aspacem at each frame (cache-accelerated, > +# of course) to check each page it visits is accessible. I have a patch to do that ;-) I've attached it - it doesn't do any caching at the moment though. Of course we should also try and unify the two different stack tracking schemes and generally try and do a better job of knowing where the stack for each thread is. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Bart V. A. <bar...@gm...> - 2009-07-30 05:58:18
|
On Wed, Jul 29, 2009 at 1:14 PM, Tom Hughes <to...@co...> wrote:
>
> On 29/07/09 11:57, sv...@va... wrote:
>
>> +# Like Tom says, the stack unwinder protection is bollocks.
>> +# We should junk all previous schemes and simply get the
>> +# stack unwinder to consult aspacem at each frame (cache-accelerated,
>> +# of course) to check each page it visits is accessible.
>
> I have a patch to do that ;-)
>
> I've attached it - it doesn't do any caching at the moment though.
>
> Of course we should also try and unify the two different stack tracking schemes and generally try and do a better job of knowing where the stack for each thread is.
Hello Tom,
Any idea why your patch changes the output of the
memcheck/tests/x86/pushfpopf regression test ? With your patch applied
Valgrind prints one stackframe less for this regression test. The diff
I get is as follows (x86_64, gcc 4.4.1):
$ cat memcheck/tests/x86/pushfpopf*diff*
--- pushfpopf.stderr.exp 2009-03-01 11:51:11.000000000 +0100
+++ pushfpopf.stderr.out 2009-07-30 07:32:14.000000000 +0200
@@ -1,7 +1,5 @@
Conditional jump or move depends on uninitialised value(s)
at 0x........: fooble (...)
- by 0x........: main (pushfpopf_c.c:12)
Conditional jump or move depends on uninitialised value(s)
at 0x........: fooble (...)
- by 0x........: main (pushfpopf_c.c:12)
Bart.
|
|
From: Tom H. <to...@co...> - 2009-07-30 09:30:26
Attachments:
valgrind-isreadable.patch
|
On 30/07/09 06:58, Bart Van Assche wrote: > Any idea why your patch changes the output of the > memcheck/tests/x86/pushfpopf regression test ? With your patch applied > Valgrind prints one stackframe less for this regression test. The diff > I get is as follows (x86_64, gcc 4.4.1): Because it was a tad bogus - the am_is_readable routine expected start and length but the stack unwinder was passing it start and end instead. The attached one should work a bit better... Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Bart V. A. <bar...@gm...> - 2009-07-30 10:34:20
|
On Thu, Jul 30, 2009 at 11:30 AM, Tom Hughes <to...@co...> wrote: > On 30/07/09 06:58, Bart Van Assche wrote: > > Any idea why your patch changes the output of the >> memcheck/tests/x86/pushfpopf regression test ? With your patch applied >> Valgrind prints one stackframe less for this regression test. The diff >> I get is as follows (x86_64, gcc 4.4.1): >> > > Because it was a tad bogus - the am_is_readable routine expected start and > length but the stack unwinder was passing it start and end instead. > > The attached one should work a bit better... > Thanks for the quick update. With the second version of the valgrind-isreadable.patch the output of "make regtest" is now the same as without this patch on openSUSE 11.1. Another issue (probably a long-standing issue) that I noticed yesterday is that the backtraces printed by Valgrind seem to depend on subtleties of the platform Valgrind is running on. On some platforms I see the filename and linenumber for the stackframe referring to main() (as expected), sometimes I see "(below main)" printed for the stackframe referring to main() (not expected). An example: With openSUSE 11.1 x86_64: $ ./vg-in-place --tool=drd --check-stack-var=yes helgrind/tests/tc09_bad_unlock ... ==13368== Destroying locked mutex: mutex 0x7fefffb70, recursion count 1, owner 1. ==13368== at 0x40085E: nearly_main (tc09_bad_unlock.c:45) ==13368== by 0x400868: main (tc09_bad_unlock.c:49) ... With openSUSE 11.0 x86_64: $ ./vg-in-place --tool=drd --check-stack-var=yes helgrind/tests/tc09_bad_unlock ... ==23627== Destroying locked mutex: mutex 0x7ff000070, recursion count 1, owner 1. ==23627== at 0x40085E: nearly_main (tc09_bad_unlock.c:45) ==23627== by 0x5067585: (below main) (in /lib64/libc-2.9.so) ... Any idea what might be the cause of this last issue ? Bart. |
|
From: Nicholas N. <n.n...@gm...> - 2009-07-30 11:48:14
|
On Thu, Jul 30, 2009 at 8:34 PM, Bart Van Assche<bar...@gm...> wrote: > > Another issue (probably a long-standing issue) that I noticed yesterday is > that the backtraces printed by Valgrind seem to depend on subtleties of the > platform Valgrind is running on. On some platforms I see the filename and > linenumber for the stackframe referring to main() (as expected), sometimes I > see "(below main)" printed for the stackframe referring to main() (not > expected). If you use --show-below-main in the latter case you'll get the actual symbol names. Doesn't explain the difference, though. Could be a compiler difference. Nick |