valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Wrong function names (or line numbers) in ms_print output

[Philippe W. <phi...@sk...>]

On Tue, 2015-12-08 at 14:39 -0800, Nikolaus Rath wrote:

> $ valgrind --version
> valgrind-3.8.1
This is more than 3 years old.
Would be (much) better to upgrade to the last version (3.11).
In any case, if the problem is related to inlining, you need
a recent valgrind version to see it (inlining info was implemented
in 3.10).

> Inlining was what came to my mind at first too. But in my experience 
> this only causes a difference of a few lines - not more than 2000.
The difference will only depend on where the inlining and inlined
functions are, and these do not need to be close to each other.


> Hmm. This is interesting. If I ask gcc for a backtrace, it just hangs:
...
> After pressing Ctrl-C:
> 
> #8  0x0000000000ba1ec8 in h5dump_attr_double (loc_id=1,
> ^C    f=<error reading variable: Cannot access memory at address 
> 0xa000008>, name=Quit
> 
> 
> Might this have something to do with the problem?
Maybe : it is possible that ifort generates unusual code/debug info,
that gdb and/or valgrind unwinder do not understand.
You might also maybe upgrade gdb (if you are using an old gdb version).

> 
> 
> That said, I don't think the above backtrace is the right one, because 
> H5FL_reg_calloc is called via a ton of different code paths. Is there a 
> way to break in this function only when entered via the codepath that 
> valgrind gave above?
No (easy) way that I know.
So, you will have to put a break in the function that is most likely
to be called only in the interesting stacktrace, and then put a break
on H5FL_reg_calloc and continue.

Philippe

Re: [Valgrind-users] Wrong function names (or line numbers) in ms_print output

[Nikolaus R. <nr...@tr...>]

On 12/08/2015 02:26 PM, Philippe Waroquiers wrote:
> On Tue, 2015-12-08 at 09:08 -0800, Nikolaus Rath wrote:
>> Hello,
>>
>> I'm having a problem using massif. When looking at the ms_print output, I'm getting entries like this:
>>
>> ->10.77% (11,146,544B) 0xF4AC9C: H5FL_reg_calloc (in /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model)
>> | ->10.58% (10,946,896B) 0x1000D57: H5S_copy (in /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model)
>> | | ->10.57% (10,940,640B) 0xEE0A80: H5A_create (in /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model)
>> | | | ->10.57% (10,940,640B) 0xEDAAAF: H5Acreate2 (in /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model)
>> | | |   ->10.57% (10,940,640B) 0xEC985C: h5acreate_c_ (in /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model)
>> | | |     ->10.57% (10,940,640B) 0xEC3C55: h5a_mp_h5acreate_f_ (in /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model)
>> | | |       ->10.57% (10,940,640B) 0xB99ED5: taehdf5_mp_h5append_data_double_0d_ (taehdf5.f90:1936)
>> | | |         ->04.24% (4,387,296B) in 40 places, all below massif's threshold (01.00%)
>>
>>
>> However, line 1936 of taehdf5.f90 is actually inside a different subroutine, defined as:
>>
>> subroutine h5dump_attr_int(loc_id,f,name)
>> [..]
>>      ! next line is 1936
>>      call h5acreate_f(loc_id,name,H5T_NATIVE_INTEGER,space_id,attr_id,hdferr)
>> [...]
>> end subroutine
>>
>>
>> The h5append_data_double_0d subroutine is actually defined much later, starting in line 4120 with:
>>
>>    subroutine h5append_data_double_0d(group_id,f,name)
>>
>> ..and it does not contain any calls to h5acreate_f. So I think that probably the line number is correct, but the function name is not.
>>
>> Does anyone know what might cause this?
 >
> What is the platform ? (version of valgrind/os/gcc, which cpu, ....) ?

$ uname -a
Linux ibm-h1.localcluster 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10 
22:19:54 EST 2013 x86_64 x86_64 x86_64 GNU/Linux

$ cat /proc/cpuinfo  | head -10
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 62
model name	: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
stepping	: 4
cpu MHz		: 1200.000
cache size	: 20480 KB
physical id	: 0
siblings	: 8

$ valgrind --version
valgrind-3.8.1

The binary I'm analyzing has been compiled with

$ ifort --version
ifort (IFORT) 15.0.0 20140723
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.


> Strange stacktraces can be given in case the compiler is inlining some
> calls or if Valgrind unwinder has a bug.

Inlining was what came to my mind at first too. But in my experience 
this only causes a difference of a few lines - not more than 2000.

> You might check that using gdb+vgdb: put a break on H5FL_reg_calloc.
> When break encountered, do
>    (gdb) backtrace

Hmm. This is interesting. If I ask gcc for a backtrace, it just hangs:

(gdb) b H5FL_reg_calloc
Breakpoint 4 at 0xf4abf0
(gdb) c
Continuing.

Breakpoint 4, 0x0000000000f4abf0 in H5FL_reg_calloc ()
(gdb) backtrace
#0  0x0000000000f4abf0 in H5FL_reg_calloc ()
#1  0x0000000000fada52 in H5O_attr_shared_decode ()
#2  0x0000000000fd0f7c in H5O_msg_iterate_real ()
#3  0x0000000000fb411b in H5O_attr_exists ()
#4  0x0000000000ee08ab in H5A_create ()
#5  0x0000000000edaab1 in H5Acreate2 ()
#6  0x0000000000ec985e in h5acreate_c_ ()
#7  0x0000000000ec3c57 in h5a_mp_h5acreate_f_ ()
#8  0x0000000000ba1ec8 in h5dump_attr_double (loc_id=1,

After pressing Ctrl-C:

#8  0x0000000000ba1ec8 in h5dump_attr_double (loc_id=1,
^C    f=<error reading variable: Cannot access memory at address 
0xa000008>, name=Quit


Might this have something to do with the problem?


That said, I don't think the above backtrace is the right one, because 
H5FL_reg_calloc is called via a ton of different code paths. Is there a 
way to break in this function only when entered via the codepath that 
valgrind gave above?


Thanks for your help,
-Nikolaus

Re: [Valgrind-users] Wrong function names (or line numbers) in ms_print output

[Philippe W. <phi...@sk...>]

On Tue, 2015-12-08 at 09:08 -0800, Nikolaus Rath wrote:
> Hello,
> 
> I'm having a problem using massif. When looking at the ms_print output, I'm getting entries like this:
> 
> ->10.77% (11,146,544B) 0xF4AC9C: H5FL_reg_calloc (in /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model)
> | ->10.58% (10,946,896B) 0x1000D57: H5S_copy (in /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model)
> | | ->10.57% (10,940,640B) 0xEE0A80: H5A_create (in /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model)
> | | | ->10.57% (10,940,640B) 0xEDAAAF: H5Acreate2 (in /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model)
> | | |   ->10.57% (10,940,640B) 0xEC985C: h5acreate_c_ (in /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model)
> | | |     ->10.57% (10,940,640B) 0xEC3C55: h5a_mp_h5acreate_f_ (in /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model)
> | | |       ->10.57% (10,940,640B) 0xB99ED5: taehdf5_mp_h5append_data_double_0d_ (taehdf5.f90:1936)
> | | |         ->04.24% (4,387,296B) in 40 places, all below massif's threshold (01.00%)
> 
> 
> However, line 1936 of taehdf5.f90 is actually inside a different subroutine, defined as:
> 
> subroutine h5dump_attr_int(loc_id,f,name)
> [..]    
>     ! next line is 1936 
>     call h5acreate_f(loc_id,name,H5T_NATIVE_INTEGER,space_id,attr_id,hdferr)
> [...]
> end subroutine
> 
> 
> The h5append_data_double_0d subroutine is actually defined much later, starting in line 4120 with:
> 
>   subroutine h5append_data_double_0d(group_id,f,name)
> 
> ..and it does not contain any calls to h5acreate_f. So I think that probably the line number is correct, but the function name is not.
> 
> Does anyone know what might cause this?
What is the platform ? (version of valgrind/os/gcc, which cpu, ....) ?


Strange stacktraces can be given in case the compiler is inlining some
calls or if Valgrind unwinder has a bug.

You might check that using gdb+vgdb: put a break on H5FL_reg_calloc.
When break encountered, do
  (gdb) backtrace
  (gdb) monitor v.info scheduler
This will allow to compare:
   the backtrace produced by gdb
   the stacktrace produced by Valgrind (using inline info)
and the stacktrace produced by massif in its output file.
If the first 2 stacktraces are as expected, but the massif stacktrace
is not, then that is probably because massif does not use inline info
to produce its output.

If the gdb backtrace is ok, but the monitor stack trace is not,
then it means the valgrind unwinder does not properly  unwind your code.

Philippe


Some more background info about stacktraces and inline info:
If you run:
    valgrind --read-inline-info=no ./memcheck/tests/inlinfo
then the last stacktrace produced is:
==2277==    at 0x80485C4: fun_noninline_o (inlinfo.c:40)
==2277==    by 0x804867D: fun_noninline_n (inlinfo.c:48)
==2277==    by 0x804880D: main (inlinfo.c:72)
There is effectively a call to fun_noninline_n at line 72.
However, at line 48, we are inside the function fun_f, while the
stacktrace above shows fun_noninline_n.
When running with the (default) --read-inline-info=yes, the stacktrace
is:
==2302==    at 0x80485C4: fun_noninline_o (inlinfo.c:40)
==2302==    by 0x804867D: fun_f (inlinfo.c:48)
==2302==    by 0x804867D: fun_e (inlinfo.c:54)
==2302==    by 0x804867D: fun_noninline_n (inlinfo.c:60)
==2302==    by 0x804880D: main (inlinfo.c:72)

which is then understandable: when there is inlining, the line
nr corresponds to the (last) inlined function, but the function name
corresponds to the 'inlining' function.

Massif does not expand inlined function calls (so, produces stacktraces
as if --read-inline-info=no was given).
See the call to VG_(describe_IP) in ms_main.c:  it has a NULL second
argument.

[Valgrind-users] Wrong function names (or line numbers) in ms_print output

[Nikolaus R. <nr...@tr...>]

Hello,

I'm having a problem using massif. When looking at the ms_print output, I'm getting entries like this:

->10.77% (11,146,544B) 0xF4AC9C: H5FL_reg_calloc (in /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model)
| ->10.58% (10,946,896B) 0x1000D57: H5S_copy (in /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model)
| | ->10.57% (10,940,640B) 0xEE0A80: H5A_create (in /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model)
| | | ->10.57% (10,940,640B) 0xEDAAAF: H5Acreate2 (in /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model)
| | |   ->10.57% (10,940,640B) 0xEC985C: h5acreate_c_ (in /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model)
| | |     ->10.57% (10,940,640B) 0xEC3C55: h5a_mp_h5acreate_f_ (in /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model)
| | |       ->10.57% (10,940,640B) 0xB99ED5: taehdf5_mp_h5append_data_double_0d_ (taehdf5.f90:1936)
| | |         ->04.24% (4,387,296B) in 40 places, all below massif's threshold (01.00%)


However, line 1936 of taehdf5.f90 is actually inside a different subroutine, defined as:

subroutine h5dump_attr_int(loc_id,f,name)
[..]    
    ! next line is 1936 
    call h5acreate_f(loc_id,name,H5T_NATIVE_INTEGER,space_id,attr_id,hdferr)
[...]
end subroutine


The h5append_data_double_0d subroutine is actually defined much later, starting in line 4120 with:

  subroutine h5append_data_double_0d(group_id,f,name)

..and it does not contain any calls to h5acreate_f. So I think that probably the line number is correct, but the function name is not.

Does anyone know what might cause this?


Best,
-Nikolaus

Re: [Valgrind-users] some questions about valgrind massif

[Philippe W. <phi...@sk...>]

On Mon, 2015-12-07 at 11:49 +0800, yoma sophian wrote:

> I use vgdb and try to create snapshop with command, "monitor
> detailed_snapshot xxx"
> No matter I create snapshop before mmap or after mmap, I hightlight in
> the below program, there is still no mmap information in the detail
> snapshop file.
> It seems the mmap is not recorded by massif even I manual trigger the snapshop.
> If I miss anything or do any wrong experiment, please let me know.
The mmap is probably below the massif threshold, and so is not shown.
Either mmap more memory or decrease the massif --threshold value.

Philippe

Re: [Valgrind-users] DRD: pt_threadid != INVALID_POSIX_THREADID assertion

[Jonathan R. J. <Jon...@ef...>]

Hi All,

I was able to make a simple program to reproduce it.

See [1] for more details.

TL;DR: dlopen, call function with pthread_create, drd fails on assert.

[1] https://bugs.kde.org/show_bug.cgi?id=356374

Cheers!

On 2015-12-07 09:44 AM, Jonathan Rajotte Julien wrote:
> Hi,
>
> I was trying to use the DRD tool on one of our instrumented application
> (tracing via lttng) and I get an assertion [4] similar to the one from
> this post [1].
> Just like Joe VanAdel I'm wondering whether the problem is on our side
> (lttng) or DRD.
>
> The lttng-ust lib essentially get preloaded and create a thread during
> it's initialization.
> You can find the relevant code for lttng-ust here [3].
>
> A way to reproduce this is to install lttng-ust [3] and use drd on
> the example under lttng-ust/doc/examples/easy-ust/
>
> Let me know if you need any additional information.
>
> Thanks
>
> [1] http://thread.gmane.org/gmane.comp.debugging.valgrind/13995/focus=13996
>
> [2] https://github.com/lttng/lttng-ust
>
> It require liburcu: https://github.com/urcu/userspace-rcu
>
> [3]
> The init function :
> https://github.com/lttng/lttng-ust/blob/master/liblttng-ust/lttng-ust-comm.c#L1483
>
> The actual call to pthread_create:
> https://github.com/lttng/lttng-ust/blob/master/liblttng-ust/lttng-ust-comm.c#L1560
>
> [4]
>
> ==16669== drd, a thread error detector
> ==16669== Copyright (C) 2006-2015, and GNU GPL'd, by Bart Van Assche.
> ==16669== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
> ==16669== Command: ./sample
> ==16669==
> --16669-- WARNING: unhandled amd64-linux syscall: 324
> --16669-- You may be able to write your own handler.
> --16669-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
> --16669-- Nevertheless we consider this a bug.  Please report
> --16669-- it at http://valgrind.org/support/bug_reports.html.
>
> drd: drd_thread.c:657 (vgDrd_thread_entering_pthread_create): Assertion
> 'DRD_(g_threadinfo)[tid].pt_threadid != INVALID_POSIX_THREADID' failed.
>
> host stacktrace:
> ==16669==    at 0x380256C8: show_sched_status_wrk (m_libcassert.c:343)
> ==16669==    by 0x380257D4: report_and_quit (m_libcassert.c:415)
> ==16669==    by 0x38025961: vgPlain_assert_fail (m_libcassert.c:481)
> ==16669==    by 0x38014E36: vgDrd_thread_entering_pthread_create
> (drd_thread.c:657)
> ==16669==    by 0x3800944B: handle_client_request (drd_clientreq.c:296)
> ==16669==    by 0x3803D040: wrap_tool_handle_client_request
> (m_tooliface.c:280)
> ==16669==    by 0x3807526F: do_client_request (scheduler.c:2101)
> ==16669==    by 0x3807526F: vgPlain_scheduler (scheduler.c:1425)
> ==16669==    by 0x380839EA: thread_wrapper (syswrap-linux.c:102)
> ==16669==    by 0x380839EA: run_a_thread_NORETURN (syswrap-linux.c:155)
>
> sched status:
>     running_tid=1
>
> Thread 1: status = VgTs_Runnable (lwpid 16669)
> ==16669==    at 0x4C3167B: vgDrd_entering_pthread_create
> (drd_pthread_intercepts.c:441)
> ==16669==    by 0x4C3167B: pthread_create_intercept
> (drd_pthread_intercepts.c:594)
> ==16669==    by 0x4C3167B: pthread_create@* (drd_pthread_intercepts.c:611)
> ==16669==    by 0x50696BD: lttng_ust_init (lttng-ust-comm.c:1560)
> ==16669==    by 0x4010139: call_init.part.0 (dl-init.c:78)
> ==16669==    by 0x4010222: call_init (dl-init.c:36)
> ==16669==    by 0x4010222: _dl_init (dl-init.c:126)
> ==16669==    by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
>
>
>
>

-- 
Jonathan R. Julien
Efficios

[Valgrind-users] DRD: pt_threadid != INVALID_POSIX_THREADID assertion

[Jonathan R. J. <Jon...@ef...>]

Hi,

I was trying to use the DRD tool on one of our instrumented application 
(tracing via lttng) and I get an assertion [4] similar to the one from 
this post [1].
Just like Joe VanAdel I'm wondering whether the problem is on our side 
(lttng) or DRD.

The lttng-ust lib essentially get preloaded and create a thread during 
it's initialization.
You can find the relevant code for lttng-ust here [3].

A way to reproduce this is to install lttng-ust [3] and use drd on
the example under lttng-ust/doc/examples/easy-ust/

Let me know if you need any additional information.

Thanks

[1] http://thread.gmane.org/gmane.comp.debugging.valgrind/13995/focus=13996

[2] https://github.com/lttng/lttng-ust

It require liburcu: https://github.com/urcu/userspace-rcu

[3]
The init function : 
https://github.com/lttng/lttng-ust/blob/master/liblttng-ust/lttng-ust-comm.c#L1483 

The actual call to pthread_create: 
https://github.com/lttng/lttng-ust/blob/master/liblttng-ust/lttng-ust-comm.c#L1560

[4]

==16669== drd, a thread error detector
==16669== Copyright (C) 2006-2015, and GNU GPL'd, by Bart Van Assche.
==16669== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==16669== Command: ./sample
==16669==
--16669-- WARNING: unhandled amd64-linux syscall: 324
--16669-- You may be able to write your own handler.
--16669-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--16669-- Nevertheless we consider this a bug.  Please report
--16669-- it at http://valgrind.org/support/bug_reports.html.

drd: drd_thread.c:657 (vgDrd_thread_entering_pthread_create): Assertion 
'DRD_(g_threadinfo)[tid].pt_threadid != INVALID_POSIX_THREADID' failed.

host stacktrace:
==16669==    at 0x380256C8: show_sched_status_wrk (m_libcassert.c:343)
==16669==    by 0x380257D4: report_and_quit (m_libcassert.c:415)
==16669==    by 0x38025961: vgPlain_assert_fail (m_libcassert.c:481)
==16669==    by 0x38014E36: vgDrd_thread_entering_pthread_create 
(drd_thread.c:657)
==16669==    by 0x3800944B: handle_client_request (drd_clientreq.c:296)
==16669==    by 0x3803D040: wrap_tool_handle_client_request 
(m_tooliface.c:280)
==16669==    by 0x3807526F: do_client_request (scheduler.c:2101)
==16669==    by 0x3807526F: vgPlain_scheduler (scheduler.c:1425)
==16669==    by 0x380839EA: thread_wrapper (syswrap-linux.c:102)
==16669==    by 0x380839EA: run_a_thread_NORETURN (syswrap-linux.c:155)

sched status:
   running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 16669)
==16669==    at 0x4C3167B: vgDrd_entering_pthread_create 
(drd_pthread_intercepts.c:441)
==16669==    by 0x4C3167B: pthread_create_intercept 
(drd_pthread_intercepts.c:594)
==16669==    by 0x4C3167B: pthread_create@* (drd_pthread_intercepts.c:611)
==16669==    by 0x50696BD: lttng_ust_init (lttng-ust-comm.c:1560)
==16669==    by 0x4010139: call_init.part.0 (dl-init.c:78)
==16669==    by 0x4010222: call_init (dl-init.c:36)
==16669==    by 0x4010222: _dl_init (dl-init.c:126)
==16669==    by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)




-- 
Jonathan R. Julien
Efficios


-- 
Jonathan R. Julien
Efficios

Re: [Valgrind-users] POW() function behaving different when running in valgrind?

[John R. <jr...@bi...>]

> Duplicating the discussion from the V8 user group:
>
>     https://groups.google.com/forum/#!topic/v8-users/qRorKvYNq24
>
>     On Fri, Dec 4, 2015 at 3:26 PM, Wilfried Gösgens <do...@gm...> wrote:
>      > Hi everyone
>      > Using the regular d8 shell:
>      >
>      >     # ./d8
>      >     V8 version 4.8.271.5
>      >     d8> Math.pow(0, 0.1);
>      >     0
>      >     d8>
>      >
>      > gives proper results.
>      > But using d8 in valgrind gives:
>      >
>      >     /usr/bin/valgrind.bin --log-file=/tmp/valgrindlog.%p
>      > --show-reachable=yes --leak-check=full ./d8
>      >     Math.pow(0, 0.1);
>      >     V8 version 4.8.271.5
>      >     d8> NaN
>      >     d8>

> Does valgrind replace mathematical functions?

No, but valgrind forces round-to-nearest 64-bit result
for every floating-point operation: no extra precision
nor exponent range for 80-bit extended opcodes,
and no directed rounding (truncate, ceil, floor).  This is
well documented.  Thus if the user code relies on 80-bit mode
or rounding other than round-to-nearest, then "bad results"
may ensue.  The bug is in V8 not diagnosing the actual environment
before proceeding.  Never run a laboratory experiment
for quantitative results without first calibrating the instruments.

Re: [Valgrind-users] POW() function behaving different when running in valgrind?

[Tom H. <to...@co...>]

On 07/12/15 11:40, Wilfried Goesgens wrote:

> Does valgrind replace mathematical functions?

No, but see the section on x86/AMD64 floating point support in the manual:

http://valgrind.org/docs/manual/manual-core.html#manual-core.limits

Tom


-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] POW() function behaving different when running in valgrind?

[Wilfried G. <dot...@ci...>]

Hi Everyone,  

Duplicating the discussion from the V8 user group:  
>  
>
>https://groups.google.com/forum/#!topic/v8-users/qRorKvYNq24    On Fri, Dec
>4, 2015 at 3:26 PM, Wilfried Gösgens <doth...@gmailcom> wrote: 
>> Hi everyone 
>> Using the regular d8 shell: 
>> 
>>     # ./d8 
>>     V8 version 4.8.271.5 
>>     d8> Math.pow(0, 0.1); 
>>     0 
>>     d8> 
>> 
>> gives proper results. 
>> But using d8 in valgrind gives: 
>> 
>>     /usr/bin/valgrind.bin --log-file=/tmp/valgrindlog.%p 
>> --show-reachable=yes --leak-check=full ./d8 
>>     Math.pow(0, 0.1); 
>>     V8 version 4.8.271.5 
>>     d8> NaN 
>>     d8> 
>> 
>> Is this a bug in V8 or in Valgrind? 
>
>  
>
>  
>
>I can reproduce what you describe and it doesn't go away when you pass 
>--smc-check=all to Valgrind or --nofast_math to V8. 
> 
>I'm inclined to suspect Valgrind but I'm honestly not sure.  `pow(0, 
>0.1)` from C code or a Perl script doesn't exhibit the same behavior. 
>Those may not be issuing the same instructions, of course.  

  

d8 is the sample shell provided by the V8 project for testing the V8
javascript engine.  

It will be built alongside the V8 engine:
https://developers.google.com/v8/build?hl=en  

Does valgrind replace mathematical functions?  

   

Cheers,  

Willi

Re: [Valgrind-users] some questions about valgrind massif

[yoma s. <sop...@gm...>]

hi Philippe:

> There is no free information in the massif outputs.
> massif only produces a sequence of snaphots, each snapshot gives
> the memory still allocated at the snapshot time.
>
> The memory allocated by main returns to 0, because all the memory
> allocated by main is freed. The graph effectively shows the absolute
> value of the memory allocated at the snapshot time.
> massif does not record the free stacktraces, it only records how
> much memory is allocated by a stacktrace (and this amount decreases
> when free is called).
>
> So, in summary:
>   * massif does *not* record 'free' stacktraces
>   * massif *only* record 'malloc' stacktraces
>   * massif maintains the memory allocated by a stacktrace
>     this amount is decreased when free is called.
>
> So, do not expect to find some details about free stacktraces, as these
> are not recorded.
Thanks for your kind explination ^^

>
> I think there is a bug in the massif logic to make a peak detailed
> snapshot at the moment of munmap: it should try to produce a peak
> snapshot when releasing the first page of munmap, not when releasing
> the last page.
I use vgdb and try to create snapshop with command, "monitor
detailed_snapshot xxx"
No matter I create snapshop before mmap or after mmap, I hightlight in
the below program, there is still no mmap information in the detail
snapshop file.
It seems the mmap is not recorded by massif even I manual trigger the snapshop.
If I miss anything or do any wrong experiment, please let me know.

appreciate your kind help,

        f();
        g();
         /****break Here*****/
        p = mmap (0, sb.st_size, PROT_READ, MAP_SHARED, fd, 0);
        if (p == MAP_FAILED) {
/****break Here*****/
                perror ("mmap");
                return 1;
        }

Re: [Valgrind-users] some questions about valgrind massif

[Philippe W. <phi...@sk...>]

On Mon, 2015-12-07 at 00:08 +0800, yoma sophian wrote:

> I attach the pic, massif_test.png I got from massif-visualizer, and in
> the pic, the heap allocated by main will decreased to 0.
> But f and g these 2 functions will not.
> What makes me curious is I cannot find the free information in the
> massis output ascii file.
There is no free information in the massif outputs.
massif only produces a sequence of snaphots, each snapshot gives
the memory still allocated at the snapshot time.

The memory allocated by main returns to 0, because all the memory
allocated by main is freed. The graph effectively shows the absolute
value of the memory allocated at the snapshot time.
massif does not record the free stacktraces, it only records how
much memory is allocated by a stacktrace (and this amount decreases
when free is called).

So, in summary:
  * massif does *not* record 'free' stacktraces
  * massif *only* record 'malloc' stacktraces
  * massif maintains the memory allocated by a stacktrace
    this amount is decreased when free is called.

So, do not expect to find some details about free stacktraces, as these
are not recorded.


> BTW, I have some questions about --pages-as-heap=yes
> I purposely write a  program, mmap.c, that will  map the file into the memory
> But from ms_print of mmap.c, mmap_4440, I cannot see the location of
> mmap I put in the c file.
> (I attach the c file and mass output as well)
> Shall we add more options to see the location of mmap in the program
> when enable  --pages-as-heap=yes?
The stack is only output for detailed snaphots. I believe that no
detailed snapshot is taken between the mmap and the munmap.

I think there is a bug in the massif logic to make a peak detailed 
snapshot at the moment of munmap: it should try to produce a peak
snapshot when releasing the first page of munmap, not when releasing
the last page.

Philippe

Re: [Valgrind-users] Fuzz testing with Valgrind?

[Ildar I. <il...@in...>]

I created some experimental tool called Avalanche which was a king of a fuzzer based on Valgrind.

But that was already quite a long time ago.

You can still have a look

https://code.google.com/p/avalanche/


>Вторник,  1 декабря 2015, 14:04 UTC от "Dallman, John" <joh...@si...>:
>
>I'm starting to look at fuzz testing the mathematical modelling library I work on, which reads complicated data files that are produced by end-users, and could plausibly be used to stage buffer overflow attacks. The basics obviously come first: use -fstack-protector,
take care with string manipulation functions and so on. 
> 
>But while looking at fuzzing systems such as AFL ( http://lcamtuf.coredump.cx/afl/ )
it struck me that the Valgrind execution environment could be used to write a fuzzer that could discover changes in flow of control in response to variations in input files, and thus provide a better feedback mechanism than "Load a file, see if the test program
crashes". 
> 
>Has anyone looked into this in the past? 
> 
>thanks,
> 
>-- 
>John Dallman
> 
>-----------------
>Siemens Industry Software Limited is a limited company registered in England and Wales.
>Registered number: 3476850.
>Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. 
>------------------------------------------------------------------------------
>Go from Idea to Many App Stores Faster with Intel(R) XDK
>Give your users amazing mobile app experiences with Intel(R) XDK.
>Use one codebase in this all-in-one HTML5 development environment.
>Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
>http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
>_______________________________________________
>Valgrind-users mailing list
>Val...@li...
>https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Fuzz testing with Valgrind?

[Dallman, J. <joh...@si...>]

I'm starting to look at fuzz testing the mathematical modelling library I work on, which reads complicated data files that are produced by end-users, and could plausibly be used to stage buffer overflow attacks. The basics obviously come first: use -fstack-protector, take care with string manipulation functions and so on.

But while looking at fuzzing systems such as AFL (http://lcamtuf.coredump.cx/afl/) it struck me that the Valgrind execution environment could be used to write a fuzzer that could discover changes in flow of control in response to variations in input files, and thus provide a better feedback mechanism than "Load a file, see if the test program crashes".

Has anyone looked into this in the past?

thanks,

--
John Dallman

-----------------
Siemens Industry Software Limited is a limited company registered in England and Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.

[Valgrind-users] libxml2 multithreading errors in helgrind

[Hovnatan K. <hov...@gm...>]

I have the following pretty simple program:

#include <stdlib.h>
#include <stdio.h>
#include <pthread.h>
#include <libxml/parser.h>
#include <libxml/catalog.h>
#include <libxml/tree.h>
#include <libxml/HTMLparser.h>

static const int kHTMLParseFlags =
    HTML_PARSE_NOBLANKS | HTML_PARSE_NOERROR |
HTML_PARSE_NOWARNING | HTML_PARSE_NONET;

void* test1(void* ptr) {
    htmlDocPtr doc = htmlReadFile("http://www.google.com", NULL,
kHTMLParseFlags);
    xmlFreeDoc(doc);
}

void* test2(void* ptr) {
    htmlDocPtr doc = htmlReadFile("http://www.lenta.ru", NULL,
kHTMLParseFlags);
    xmlFreeDoc(doc);
}

int main(void)
{
    xmlInitParser();
    xmlInitializeCatalog();
    pthread_t thread1, thread2;
    pthread_create(&thread1, NULL,  &test1, NULL);
    pthread_create(&thread2, NULL,  &test2, NULL);
    pthread_join(thread1, NULL);
    pthread_join(thread2, NULL);
    xmlCatalogCleanup();
    xmlCleanupParser();
    return EXIT_SUCCESS;
}


When I run it in `valgrind --tool=helgrind` it shows many race conditions.
What is the reason for this? It seems that `libxml2` is thread safe. I'm
compiling with `gcc -I/usr/include/libxml2 temp.c -lxml2 -pthread`.

Thanks,
Hovnatan

Re: [Valgrind-users] Removal of db-attach

[Philippe W. <phi...@sk...>]

On Sun, 2015-11-29 at 11:06 -0800, John Reiser wrote:

> > [[snip]]
> > * with valgrind 3.11 and gdb 7.10, gdb will automatically discover
> >    the executable being debugged.
> 
> gdb is likely to become confused if there is more than one candidate.
> Running two sessions side-by-side for A-B comparison is common.
Confusion should not happen, as valgrind 3.11 gdbserver reports the
executable to debug to gdb, using 'qXfer:exec-file:read' packet.

Philippe

Re: [Valgrind-users] Removal of db-attach

[John R. <jr...@bi...>]

On 11/29/2015 09:44 AM, Philippe Waroquiers wrote:
> On Sat, 2015-11-28 at 18:42 +0100, Maurice van der Pot wrote:
>> Unfortunately the removal of --db-attach seems to make things less
>> convenient.
> Yes, for simple examination of the error context of one single thread,
> --db-attach=yes was easy.

Very often I met bad context, wrong source line, or inability
to quit the application.  Instead, vgdb gets everything correct.
Good riddance to the demise of --db-attach.

> I am not completely sure how straightforward it would be to launch
> gdb+vgdb from valgrind itself (a.o. I am wondering about the interaction
> for stdin between gdb and the application).

Yes!  Establishing separate stdin, ctty, and process group for signals
is effectively impossible for valgrind to do by itself.  In contrast
it is trivial for the user's favorite terminal emulator environment,
such as graphical desktop, 'screen', 'tmux', etc.
Side note: copy+paste can perform all connections;
"typing" (keystrokes) can be avoided for setup if gdb is on $PATH.
Learn the keyboard commands of your terminal environment for
switching focus (keyboard and/or display).

> [[snip]]
> * with valgrind 3.11 and gdb 7.10, gdb will automatically discover
>    the executable being debugged.

gdb is likely to become confused if there is more than one candidate.
Running two sessions side-by-side for A-B comparison is common.

Re: [Valgrind-users] Removal of db-attach

[Philippe W. <phi...@sk...>]

On Sat, 2015-11-28 at 18:42 +0100, Maurice van der Pot wrote:
> Unfortunately the removal of --db-attach seems to make things less
> convenient.
Yes, for simple examination of the error context of one single thread,
--db-attach=yes was easy.

I am not completely sure how straightforward it would be to launch
gdb+vgdb from valgrind itself (a.o. I am wondering about the interaction
for stdin between gdb and the application).

In the meantime, something like the below small shell script will help.
It should give the same user experience (or better, due to vgdb more
powerful functionality?).

#! /bin/sh
cat >./vgdb-hooks.gdb <<EOF
define hook-continue
  set variable \$continued_once = 1
end
define hook-stop
  if \$_thread
    if \$continued_once
      monitor v.info last_error
    end
  else
    if \$continued_once
      quit
    end
  end
end
EOF

xfce4-terminal \
   -e "gdb -ex 'source ./vgdb-hooks.gdb'
           -ex 'target remote | vgdb --wait=10'
           -ex continue  " &
valgrind --vgdb-error=0 "$@"





Some small updates might be needed, or improvements might be done:
* replace xfce4-terminal by your preferred terminal
* with valgrind 3.11 and gdb 7.10, gdb will automatically discover
  the executable being debugged. The above is based on these versions.
  Otherwise, you will have to scan the "$@" args to find the executable
  name (i.e. first argument not being a valgrind arg) and give it to
  gdb as last argument
* with the above, valgrind will always show the last error, even
  if in fact the application stops due to a break or signal or ...
  A valgrind monitor command 'v.info new_errors' could be done to only
  show the new error(s) since last request to show errors.
* you might increase --wait=10 to give enough time to valgrind to start.
  Otherwise, you could write a loop to discover the new vgdb FIFO

Philippe

[Valgrind-users] Removal of db-attach

[Maurice v. d. P. <gri...@kf...>]

I know I'm quite late with this. I only just found the information about
deprecation of --db-attach in the changelog and Florian's message about
it to this list in July of this year.

Nevertheless, I have to say that the removal of --db-attach is in my
opinion quite a step back from a usability perspective.

Valgrind has always been the one program of its kind that you could just
run on an executable that you already had and would immediately give
useful results. It has sensible defaults that keep the number of command
line options you need to specify down to a minimum.

Unfortunately the removal of --db-attach seems to make things less
convenient.

In the past I had to do the following for a simple session:
* specify a single command line option
* press n or y to continue or debug

Now I have to:
* specify a command line option
* open a second terminal
* type the full path to my executable (or navigate there) and start gdb
* type target remote | vgdb
* switch to the original terminal to check what error was given
* switch back to the gdb terminal to continue or debug

I appreciate that the built-in gdb server is an improvement over the
previous solution, but is it not possible to keep the user experience as
easy as before? If valgrind could launch gdb in the same terminal and
connect it to itself that would make the (for me) common case as easy as
it was before.

Best regards,
Maurice.

-- 
Maurice van der Pot

Kdiff3 developer   gri...@kf...   http://kdiff3.sourceforge.net
Tdiff3 developer                            https://github.com/Griffon26/tdiff3

Re: [Valgrind-users] some questions about valgrind massif

[Philippe W. <phi...@sk...>]

On Wed, 2015-11-25 at 13:32 +0800, yoma sophian wrote:
> hi philippe
> 
> > massif does not provide information about where memory was freed.
> > It shows the memory used by your program, and where it was allocated.
> >
> > For what reason do you want to know where some memory was freed ?
> if there is no free information output by massif, how could
> massif-visualizer show the heap memory usage decreased with thinner
> color bar if some function call free?
> (take the web side sample for example, the color of main in
> massif-visualizer will get thinner at the end of UI output)
> I cannot see any free information in the ms_print
I do not know to what color bar you refer, but I guess that the decrease
of memory is detected by comparing 2 successive snapshots.
Massif records the stack trace of each malloc, and for each such
stacktrace, maintains the memory (still) allocated by this stack trace.
In other words, massif observes the free calls to decrease the memory
allocated by a stacktrace, but massif does not record the stacktraces
that are calling free, and does not maintain stats about such 'free
stacktraces'.

Maybe you could explain why you need to have the free stacktraces ?
This might maybe point at other tools (memcheck ? callgrind ? dhat ?)
that will help to achieve what you need/want.

> 
> > You are welcome. Note that such type of questions is well suited
> > on valgrind-users. valgrind-developers is more used for questions
> > about valgrind development itself. So, no need to send the question
> > on both mailing lists.
> 
> Originally I thought maybe my question may nedd to modify source or
> compile option.
> Sorry for sending to 2 mailing lists ^^
> 
> BTW, I found the massif output seems only created when program exit.
> 
> is there any option or some modifification for valgrind to generate
> massif.out in a period of time or by specific event, such as user add
> special code in program or press specia button, etc?
> Since I am using valgrind to profile a daemon heap usage when it
> runing before and after some specific function, but
> that mean I have to kill the daemon before and after running function.
> And that is quite inconvinent.
You can trigger massif snaphots, using massif monitor commands either:
* from the shell, using vgdb
* from gdb, using gdb+vgdb
* from your program, using the client request
   VALGRIND_MONITOR_COMMAND(command)

See
http://www.valgrind.org/docs/manual/ms-manual.html#ms-manual.monitor-commands
for the list of massif monitor commands.

Philippe

Re: [Valgrind-users] some questions about valgrind massif

[yoma s. <sop...@gm...>]

hi philippe

> massif does not provide information about where memory was freed.
> It shows the memory used by your program, and where it was allocated.
>
> For what reason do you want to know where some memory was freed ?
if there is no free information output by massif, how could
massif-visualizer show the heap memory usage decreased with thinner
color bar if some function call free?
(take the web side sample for example, the color of main in
massif-visualizer will get thinner at the end of UI output)
I cannot see any free information in the ms_print

> You are welcome. Note that such type of questions is well suited
> on valgrind-users. valgrind-developers is more used for questions
> about valgrind development itself. So, no need to send the question
> on both mailing lists.

Originally I thought maybe my question may nedd to modify source or
compile option.
Sorry for sending to 2 mailing lists ^^

BTW, I found the massif output seems only created when program exit.

is there any option or some modifification for valgrind to generate
massif.out in a period of time or by specific event, such as user add
special code in program or press specia button, etc?
Since I am using valgrind to profile a daemon heap usage when it
runing before and after some specific function, but
that mean I have to kill the daemon before and after running function.
And that is quite inconvinent.

thanks for your kind help,

Re: [Valgrind-users] some questions about valgrind massif

[Philippe W. <phi...@sk...>]

On Mon, 2015-11-23 at 23:18 +0800, yoma sophian wrote:
> hi all:
> I have some questions about massif:
> 1. from massif.out file, I cannot tell where the free is called
>     I compile the sample code in the document page as below and get
> the massif output. From the log, there are messages about where
> "malloc" is called, but I cannot find the place for "free".
>     is there any option I need to add when using massif tool or config
> I need to add when compile the valgrind?
> ( in the smple I attach, the line#28 is where "free" is called, but
> there is no such information in the massif output)
massif does not provide information about where memory was freed.
It shows the memory used by your program, and where it was allocated.

For what reason do you want to know where some memory was freed ?


> appreciate all your kind help in advance,
You are welcome. Note that such type of questions is well suited
on valgrind-users. valgrind-developers is more used for questions
about valgrind development itself. So, no need to send the question
on both mailing lists.

Philippe

Re: [Valgrind-users] some questions about valgrind massif

[yoma s. <sop...@gm...>]

hi Azat:

2015-11-23 23:33 GMT+08:00 Azat Khuzhin <a3a...@gm...>:
> On Mon, Nov 23, 2015 at 11:18:29PM +0800, yoma sophian wrote:
>> 2. there is a option call "--trace-children=yes" to capture all
>> children information.
>> is it possible to limit the specific child name for tracking?
>> if possile, should I use some other valgrind execution options or
>> modify the source code?
>
> From valgrind(1):
>     ...
>     --trace-children-skip=patt1,patt2..
>     ...
>     --trace-children-skip-by-arg=patt1,patt2..
>     ...
BTW, is there any other option that we can focus on some specific child?
Thanks for your kind help ^^

Re: [Valgrind-users] some questions about valgrind massif

[Azat K. <a3a...@gm...>]

On Mon, Nov 23, 2015 at 11:18:29PM +0800, yoma sophian wrote:
> 2. there is a option call "--trace-children=yes" to capture all
> children information.
> is it possible to limit the specific child name for tracking?
> if possile, should I use some other valgrind execution options or
> modify the source code?

>From valgrind(1):
    ...
    --trace-children-skip=patt1,patt2..
    ...
    --trace-children-skip-by-arg=patt1,patt2..
    ...

[Valgrind-users] some questions about valgrind massif

[yoma s. <sop...@gm...>]

hi all:
I have some questions about massif:
1. from massif.out file, I cannot tell where the free is called
    I compile the sample code in the document page as below and get
the massif output. From the log, there are messages about where
"malloc" is called, but I cannot find the place for "free".
    is there any option I need to add when using massif tool or config
I need to add when compile the valgrind?
( in the smple I attach, the line#28 is where "free" is called, but
there is no such information in the massif output)

2. there is a option call "--trace-children=yes" to capture all
children information.
is it possible to limit the specific child name for tracking?
if possile, should I use some other valgrind execution options or
modify the source code?

appreciate all your kind help in advance,