Re: [Valgrind-developers] valgrind: r10655 - trunk/helgrind/tests

[Bart V. A. <bar...@gm...>]

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.