valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] catchconv no usable output

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

On Thu, 2015-03-26 at 21:41 -0700, Donald Raikes wrote:

> I was expecting something more that I could feed to the stp constraint solver.
> This is all I get no matter what program I try ot test with catchconv
> and valgrind.
> 
> Any suggestions on how I can get this to work properly would be appreciated.
Unlikely someone on this list will have a precise idea about
what this catchconv tool is supposed to do and why it is
not working.

So, here are only some general advices:
* read the code of catchconv 
* enable various valgrind traces (or catchconv tool, if it has some)
   do   :    valgrind --tool=catchconv --help-debug
   to see what traces you could activate
* debug the tool : see the section 'Debugging Valgrind with GDB'
   in README_DEVELOPERS

Philippe

[Valgrind-users] catchconv no usable output

[Donald R. <don...@ny...>]

Hello,
I have integrated catchconv with valgrind 3.11.svn, and have gotten
everything to compile and link on a debian 7.8 32-bit virtual machine.

When I run the command:
valgrind --tool=catchconv --inline-path-queries=yes
--log-file=aplay.txt aplay trumpet-12.wav

All I get in the aplay.txt file is:
==13910== Catchconv, a type mismatch constraint generator
==13910== Copyright (C) 2006-7, Regents of the University of
California, Berkeley.
==13910== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==13910== Command: aplay trumpet-12.wav
==13910== Parent PID: 13900
==13910==
==13910==
XXX Stat counters:
XXX Unhandled binop: 0
XXX Unhandled unop: 0
XXX CalcCondition: 0

I was expecting something more that I could feed to the stp constraint solver.
This is all I get no matter what program I try ot test with catchconv
and valgrind.

Any suggestions on how I can get this to work properly would be appreciated.

Thanks in advance,
Donald

Re: [Valgrind-users] memcheck GC: Increasing nodes, but constant survivors

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

On Thu, 2015-03-26 at 07:31 +0100, Paul Menzel wrote:

> So the table size is increasing as do the nodes, but the survivors
> remain constant at 5657.
> 
> Is there a chance that this run will give anything useful, so that I
> should leave it running? Or is it in a kind of infinite loop and I can
> abort it?
Difficult to say without more information.
It is not abnormal to have new partially defined bytes created,
then transformed to fully initialised bytes, and then GC-ed.

This might be a consequence of a bug in your program, likely :)
Or it might be a bug in Valgrind, less likely :).

You can use gdb+vgdb to see what your program is doing under Valgrind,
and e.g. see if/where/why it is looping and/or what it is doing.

See
http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver



Philippe

[Valgrind-users] memcheck GC: Increasing nodes, but constant survivors

[Paul M. <pau...@us...>]

Dear Valgrind folks,


please CC me as I am not subscribed.

With Debian Jessie/testing and Valgrind 3.10.0 (package 1:3.10.0-4) to
debug a segmentation fault in wkhtmltopdf [1][2][3], running the
following command,

        # G_SLICE=always-malloc G_DEBUG=gc-friendly xvfb-run valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --log-file=/tmp/20150325--wkhtmltopdf.log wkhtmltopdf http://giantmonkey.de giantmonkey.pdf
        Loading page (1/2)
        [===========================================>                ] 73%

it stays at this place for over 24 hours now while one CPU core is
constantly running at 100 %.

The log is still written to and the end looks as below.
        
        […]
        ==1908== TO DEBUG THIS PROCESS USING GDB: start GDB like this
        ==1908==   /path/to/gdb wkhtmltopdf
        ==1908== and then give GDB the following command
        ==1908==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=1908
        ==1908== --pid is optional if only one valgrind process is running
        ==1908== 
        --1892-- memcheck GC: 6249 nodes, 4986 survivors ( 79.7%)
        --1892-- memcheck GC: 8837 new table size (stepup)
        --1892-- memcheck GC: 8837 nodes, 5101 survivors ( 57.7%)
        --1892-- memcheck GC: 12497 new table size (stepup)
        --1892-- memcheck GC: 12497 nodes, 5654 survivors ( 45.2%)
        --1892-- memcheck GC: 12684 new table size (driftup)
        --1892-- memcheck GC: 12684 nodes, 5657 survivors ( 44.5%)
        --1892-- memcheck GC: 12874 new table size (driftup)
        --1892-- memcheck GC: 12874 nodes, 5657 survivors ( 43.9%)
        --1892-- memcheck GC: 13067 new table size (driftup)
        --1892-- memcheck GC: 13067 nodes, 5657 survivors ( 43.2%)
        --1892-- memcheck GC: 13263 new table size (driftup)
        --1892-- memcheck GC: 13263 nodes, 5657 survivors ( 42.6%)
        --1892-- memcheck GC: 13461 new table size (driftup)
        --1892-- memcheck GC: 13461 nodes, 5657 survivors ( 42.0%)
        --1892-- memcheck GC: 13662 new table size (driftup)
        --1892-- memcheck GC: 13662 nodes, 5657 survivors ( 41.4%)
        --1892-- memcheck GC: 13866 new table size (driftup)
        --1892-- memcheck GC: 13866 nodes, 5657 survivors ( 40.7%)
        --1892-- memcheck GC: 14073 new table size (driftup)
        --1892-- memcheck GC: 14073 nodes, 5657 survivors ( 40.1%)
        --1892-- memcheck GC: 14284 new table size (driftup)
        --1892-- memcheck GC: 14284 nodes, 5657 survivors ( 39.6%)
        --1892-- memcheck GC: 14498 new table size (driftup)
        --1892-- memcheck GC: 14498 nodes, 5657 survivors ( 39.0%)
        --1892-- memcheck GC: 14715 new table size (driftup)
        --1892-- memcheck GC: 14715 nodes, 5657 survivors ( 38.4%)
        --1892-- memcheck GC: 14935 new table size (driftup)
        --1892-- memcheck GC: 14935 nodes, 5657 survivors ( 37.8%)
        --1892-- memcheck GC: 15159 new table size (driftup)
        --1892-- memcheck GC: 15159 nodes, 5657 survivors ( 37.3%)
        --1892-- memcheck GC: 15386 new table size (driftup)
        --1892-- memcheck GC: 15386 nodes, 5657 survivors ( 36.7%)
        --1892-- memcheck GC: 15616 new table size (driftup)

So the table size is increasing as do the nodes, but the survivors
remain constant at 5657.

Is there a chance that this run will give anything useful, so that I
should leave it running? Or is it in a kind of infinite loop and I can
abort it?


Thanks,

Paul


[1] http://wkhtmltopdf.org/
[2] https://github.com/wkhtmltopdf/wkhtmltopdf
[3] https://bugreports.qt.io/browse/QTBUG-41360

[Valgrind-users] Problem wrapping C functions in C++

[Andres T. <and...@ta...>]

Hi, I'm doing wrapping of functions from pthread.h library.
For example this is a wrapper:
-------------------------------------------------------------------------------------------------------
static int I_WRAP_SONAME_FNNAME_ZZ(libpthreadZdsoZd0, pthreadZucreateZAZa)
           (pthread_t *thread, const pthread_attr_t *attr, void
*(*start) (void*), void *arg)
{
    printf("call: ptrhead_create\n");
    int result;
    OrigFn fn;
    VALGRIND_GET_ORIG_FN(fn);
    CALL_FN_W_WWWW(result, fn, thread, attr, start, arg);
    return result;
}
------------------------------------------------------------------------------------------------------

In C works fine but in C++ doen't wrap pthread_create. I don't know
why because in pthread.h the functions are declared as extern c so I
shouldn't have problems with that.

I'm working with valgrind 3.10.1

Regards,
Andres.

Re: [Valgrind-users] valgrind: mmap(0x400000, 704512) failed in UME with error 22 (Invalid argument).

[Julian S. <js...@ac...>]

> valgrind: mmap(0x400000, 704512) failed in UME with error 22 (Invalid argument).
> valgrind: this can be caused by executables with very large text, data
> or bss segments.

It might be better to update the tool to the trunk, so that we don't have
to guess whether this might be due to something fixed between 3.7.0 and now.

Does the tool mess with linker options at all, and/or have very large
global arrays/data structures?

J

[Valgrind-users] valgrind: mmap(0x400000, 704512) failed in UME with error 22 (Invalid argument).

[Donald R. <don...@ny...>]

Hello,

I am using a customized version of valgrind on a debian 7.80 amd64
virtual machine. I am attempting to integrate a tool called catchconv
into valgrind. The original version of catchconv was written in 2007
and was based on valgrind 3.2.2, so I have been trying to update the
version of valgrind to 3.7.0.

I was successful in getting everything to compile, but when I run
valgrind --tool=catchconv, I am getting this error:

valgrind: mmap(0x400000, 704512) failed in UME with error 22 (Invalid argument).
valgrind: this can be caused by executables with very large text, data
or bss segments.


I did see a bug report about this problem here:
https://bugs.kde.org/show_bug.cgi?id=193413

and according to this discussion the problem stemmed from a difference
between how ld and gold linked the modules and assigned the entry
point to valgrind.
The solution that was mentioned was to include the -Wl flag on the linker.
In my make file and the log for the make of valgrind, I see the -Wl
flag used, so I am wondering what else could be causing the problem,
and how I can resolve it.

I am working on a thesis project and valgrind is a major part of the
project, so any help would be greatly appreciated.

Thanks in advance,
Donald

Re: [Valgrind-users] Query regarding valgrind build for Octeon MIPS 64 using cross compiler.

[Maran P. <mpa...@ca...>]

On 03/16/2015 10:23 AM, MUHAMMADSAHEER C wrote:
> Hi,
> I am trying to build valgrind for Octeon MIPS 64 architecture using cross compiler.
> While linking, build gives following error,
> m_main.c:(.text+0xc): undefined reference to `_gp_disp'
> Can anyone suggest how to resolve this?
> I searched in net, but could not find a proper solution.
> I used following configuration options
> --host=mips-linux-gnu  -with-float=hard  --with-arch-64=5kc --with-gnu-as --with-gnu-ld CFLAGS="-march=octeon2 -msoft-float -Wall -mabi=64 -G 0 -fPIC -mips64r2 -mplt"
Use, --host=mips64-linux-gnu to build for MIPS64

--with-arch-64=5kc --with-gnu-as --with-gnu-ld -> these are 
unrecongnised options. Remove them.

Also, do not specify "-march=octeon2" in CFLAGS, though your target is 
octeon2.

Hope these changes would fix the build.


-- 
Maran Pakkirisamy

Re: [Valgrind-users] Handling ioctl 0x30000001 in valgrind?

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

On 17/03/15 08:44, Julian Seward wrote:
>
>> I added this entry to the filecoregrind/m_syswrap/syswrap-linux.c :
>>
>>     10166 PRE(0x30000001)
>>     10167 {
>>     10168         PRINT("NVIDIA UvmInitialize ioctl");
>>     10169 }
>
> The right place to add it is PRE(sys_ioctl) and POST(sys_ioctl).
>
> A more fundamental question is, are you running a kernel with NVidia-
> specific hacks?  What is this ioctl 0x30000001 ?  What does it do?  Is
> it in the mainline linux kernel sources?

There were a couple of previous threads back in January but I don't we 
ever really got to the bottom of that question...

Tom

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

Re: [Valgrind-users] Handling ioctl 0x30000001 in valgrind?

[Julian S. <js...@ac...>]

> I added this entry to the filecoregrind/m_syswrap/syswrap-linux.c :
> 
>    10166 PRE(0x30000001)
>    10167 {
>    10168         PRINT("NVIDIA UvmInitialize ioctl");
>    10169 }

The right place to add it is PRE(sys_ioctl) and POST(sys_ioctl).

A more fundamental question is, are you running a kernel with NVidia-
specific hacks?  What is this ioctl 0x30000001 ?  What does it do?  Is
it in the mainline linux kernel sources?

J

[Valgrind-users] Query regarding valgrind build for Octeon MIPS 64 using cross compiler.

[MUHAMMADSAHEER C <sah...@sa...>]

Hi,
I am trying to build valgrind for Octeon MIPS 64 architecture using cross compiler. 
While linking, build gives following error,
m_main.c:(.text+0xc): undefined reference to `_gp_disp'
Can anyone suggest how to resolve this?
I searched in net, but could not find a proper solution.
I used following configuration options
--host=mips-linux-gnu  -with-float=hard  --with-arch-64=5kc --with-gnu-as --with-gnu-ld CFLAGS="-march=octeon2 -msoft-float -Wall -mabi=64 -G 0 -fPIC -mips64r2 -mplt" 
If you can give detailed configuration option or fix for this issue, it will be very helpful.
Best Regards,
Muhammad Saheer.C

Re: [Valgrind-users] Handling ioctl 0x30000001 in valgrind?

[Carl P. <cp...@nv...>]

*On 01/31/2015 07:07 AM, Carl Ponder wrote:*
> I ran into this output from valgrind
>
>     *==21898== Warning: noted but unhandled ioctl 0x30000001 with no
>     size/direction hints.*
>     ==21898==   This could cause spurious value errors to appear.
>     ==21898==   See README_MISSING_SYSCALL_OR_IOCTL for guidance on
>     writing a proper wrapper.
>     ==21898==   at 0x59C98C7: ioctl (in /lib64/libc-2.12.so)
>     ==21898==   by 0x61D148D: ??? (in /usr/lib64/libcuda.so.346.29)
>     ==21898==   by 0x62B7B94: ??? (in /usr/lib64/libcuda.so.346.29)
>     ==21898==   by 0x6271A6F: ??? (in /usr/lib64/libcuda.so.346.29)
>     ==21898==   by 0x61AE21C: cuInit (in /usr/lib64/libcuda.so.346.29)
>     ==21898==   by 0x414D89: __pgi_uacc_cuda_init (cuda_init.c:225)
>     ==21898==   by 0x408ACC: __pgi_uacc_enumerate (init.c:420)
>     ==21898==   by 0x408E64: __pgi_uacc_initialize (init.c:580)
>     ==21898==   by 0x405C09: __pgi_uacc_dataenterstart
>     (dataenterstart.c:45)
>     ==21898==   by 0x404A19: MAIN_ (test_synccheck.F:177)
>     ==21898==   by 0x4027F3: main (in /home-2/cponder/Temp.064/synccheck)
>
 From following the instructions in
>
>     http://valgrind.org/docs/manual/dist.readme-missing.html
>
I added this entry to the filecoregrind/m_syswrap/syswrap-linux.c :

    10166 PRE(0x30000001)
    10167 {
    10168         PRINT("NVIDIA UvmInitialize ioctl");
    10169 }

It didn't affect the output, though, I still see the same messages and 
it looks like the abovePRINT statement didn't get executed.
I saw this message in two places in thevalgrind build log:

    m_syswrap/syswrap-linux.c:10166: warning: no previous prototype for
    ‘vgSysWrap_linux_0x30000001_before’

The instructions also say this regarding system-calls:

    Also, add it to the syscall_table[] array; use one of GENX_, GENXY
         LINX_, LINXY, PLAX_, PLAXY.
         GEN* for generic syscalls (in syswrap-generic.c), LIN* for linux
         specific ones (in syswrap-linux.c) and PLA* for the platform
         dependant ones (in syswrap-$(PLATFORM)-linux.c).
         The *XY variant if it requires a PRE() and POST() function, and
         the *X_ variant if it only requires a PRE()
         function.

There isn't anysyscall_table in the syswrap-linux.c file, also I'm not 
sure if this applies to ioctl's anyway.
So the obvious questions are (a) whether I put thePRE(0x30000001) macro 
in the right file, and if there are other edits that I have to make to 
the valgrind sources as well.
This particular ioctl doesn't take any arguments and only returns an 
integer status value.
For now I just want to remove the warning-message fromvalgrind, after 
that I'll look more closely at changes it might possibly make to the 
global data state.
Thanks,

                     Carl Ponder


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

Re: [Valgrind-users] uninitialised value(s) - after explicit memset to 0 ??

[David C. R. <dra...@su...>]

On 03/10/2015 08:07 PM, David Chapman wrote:
> On 3/10/2015 5:21 PM, David C. Rankin wrote:
>> All,
>>
>>     I have an issue with valgrind-3.8.1 (openSuSE 13.1 x86_64) reporting the
>> error:
>>
>> Conditional jump or move depends on uninitialised value(s)
>>
>>     The error stems from reallocation of a new block of memory. The error is
>> triggered when iterating over the reallocated pointer array into the reallocated
>> block, despite explicitly setting/initializing values of the new pointers to 0
>> with memset (equivalent to the original allocation with calloc).
>
> Not quite.  calloc() gets the size of the object being cleared in addition to
> the number of objects, while memset() gets only the size in bytes.  You need to
> multiply cmax by sizeof(*slines), as you did for the realloc() call.  (Of
> course, "slines + cmax" on the same line of code is pointer arithmetic, so it
> automatically performs this multiplication.  C does have its warts.)
>

Hah!, Thank you David!

(smacks self, places pointed circular hat on head, and turns sadly to face the 
corner ;-)

   Sheeze, I can't believe I walked right into that one! Thanks for solving a 
'forest for the trees issue.'  I could have looked at that for 2-days and never 
snapped to the omission.

   Thanks

-- 
David C. Rankin, J.D.,P.E.

Re: [Valgrind-users] uninitialised value(s) - after explicit memset to 0 ??

[David C. <dcc...@ac...>]

On 3/10/2015 5:21 PM, David C. Rankin wrote:
> All,
>
>     I have an issue with valgrind-3.8.1 (openSuSE 13.1 x86_64) reporting the error:
>
> Conditional jump or move depends on uninitialised value(s)
>
>     The error stems from reallocation of a new block of memory. The error is
> triggered when iterating over the reallocated pointer array into the reallocated
> block, despite explicitly setting/initializing values of the new pointers to 0
> with memset (equivalent to the original allocation with calloc).

Not quite.  calloc() gets the size of the object being cleared in 
addition to the number of objects, while memset() gets only the size in 
bytes.  You need to multiply cmax by sizeof(*slines), as you did for the 
realloc() call.  (Of course, "slines + cmax" on the same line of code is 
pointer arithmetic, so it automatically performs this multiplication.  C 
does have its warts.)

-- 
     David Chapman      dcc...@ac...
     Chapman Consulting -- San Jose, CA
     Software Development Done Right.
     www.chapman-consulting-sj.com

[Valgrind-users] uninitialised value(s) - after explicit memset to 0 ??

[David C. R. <dra...@su...>]

All,

   I have an issue with valgrind-3.8.1 (openSuSE 13.1 x86_64) reporting the error:

Conditional jump or move depends on uninitialised value(s)

   The error stems from reallocation of a new block of memory. The error is 
triggered when iterating over the reallocated pointer array into the reallocated 
block, despite explicitly setting/initializing values of the new pointers to 0 
with memset (equivalent to the original allocation with calloc).

   A quick example program illustrating the issue is here:

[2.9k]
http://www.3111skyline.com/dl/dev/lists/vg_ui_values.c.txt

   .txt added for online readability. For direct d/l use:

http://www.3111skyline.com/dl/dev/lists/vg_ui_values.c

   It simply reads any text file and reallocates pointers as needed after 4 
lines are read. Compile with -DVGERR to reproduce the error. A default compile 
avoids the error by using a for loop to avoid touching what valgrind considers 
uninitialized. So in summary, compile as follow to test with/without the error:

With Error:

  gcc -Wall -Wextra -DVGERR -o vg_ui_error vg_ui_values.c

Without:

  gcc -Wall -Wextra -o vg_ui_clean vg_ui_values.c

Then simply run:

   valgrind ./vg_ui_error some_text_file

(where the text file has more than 4 lines of text)

   Since the values for the new block contents is set with memset, why does 
valgrind complain that the memory is uninitialized? Is this correct behavior for 
valgrind, or is valgrind for some reason not tracking the values set by memset 
as initialized?

   I've looked at 
http://valgrind.org/docs/manual/mc-manual.html#mc-manual.uninitvals, etc.. and I 
am unclear whether valgrind should throw this error? ...or... whether valgrind 
should correctly track the memset pointers as initialized? What say the experts?

-- 
David C. Rankin, J.D.,P.E.

Re: [Valgrind-users] Valgrind with linux daemon

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

On Tue, 2015-03-03 at 04:59 +0000, sankoor sampath wrote:
> Hi,
> 
> Am very new valgrind, pl help me out:
> I have daemon running on linux machine, in which i have injected 1MB
> memory leak & trying to find memory leak in a daemon using valgrind.
> But am not able to get the proper memory leak ouptut , Pl find the
> below the valgrind o/p:
...
> ==2476==
> 0513-059 The FSRM Subsystem has been started. Subsystem PID is 2477.
> ==2476==
Isn't the above indicating that the daemon is started as a child process
of 2476 ?

Then you should use
   --trace-children=yes
to ensure valgrind also instruments the daemon process.


Philippe

Re: [Valgrind-users] Valgrind with linux daemon

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

> Memory leak introduced as :char* skg = (char*)malloc (10000*sizeof(char));

Write the smallest possible program that contains the above statement
but also causes memcheck to report a leak.  You must run the program
under memcheck and get an actual leak report.  Thinking "it's so easy,
that definitely leaks!" is NOT sufficient.  Compare and contrast
your daemon with that smallest possible program that leaks.

[Valgrind-users] Valgrind with linux daemon

[sankoor s. <sam...@ya...>]

Hi,

Am very new valgrind, pl help me out:
I have daemon running on linux machine, in which i have injected 1MB memory leak & trying to find memory leak in a daemon using valgrind.
But am not able to get the proper memory leak ouptut , Pl find the below the valgrind o/p:
/usr/bin/valgrind --tool=memcheck --num-callers=8 --leak-check=full --leak-resolution=high --error-limit=no --show-reachable=yes --track-origins=yes startsrc -s FSRM
==2476== Memcheck, a memory error detector
==2476== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==2476== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==2476== Command: startsrc -s FSRM
==2476==
==2476== Conditional jump or move depends on uninitialised value(s)
==2476==    at 0x4018566: index (in /usr/lib64/ld-2.17.so)
==2476==    by 0x40079D3: expand_dynamic_string_token (in /usr/lib64/ld-2.17.so)
==2476==    by 0x40084F5: _dl_map_object (in /usr/lib64/ld-2.17.so)
==2476==    by 0x400160D: map_doit (in /usr/lib64/ld-2.17.so)
==2476==    by 0x400F313: _dl_catch_error (in /usr/lib64/ld-2.17.so)
==2476==    by 0x4000E8D: do_preload (in /usr/lib64/ld-2.17.so)
==2476==    by 0x4004296: dl_main (in /usr/lib64/ld-2.17.so)
==2476==    by 0x4016244: _dl_sysdep_start (in /usr/lib64/ld-2.17.so)
==2476==  Uninitialised value was created by a stack allocation
==2476==    at 0x4004224: dl_main (in /usr/lib64/ld-2.17.so)
==2476==
==2476== Conditional jump or move depends on uninitialised value(s)
==2476==    at 0x401856B: index (in /usr/lib64/ld-2.17.so)
==2476==    by 0x40079D3: expand_dynamic_string_token (in /usr/lib64/ld-2.17.so)
==2476==    by 0x40084F5: _dl_map_object (in /usr/lib64/ld-2.17.so)
==2476==    by 0x400160D: map_doit (in /usr/lib64/ld-2.17.so)
==2476==    by 0x400F313: _dl_catch_error (in /usr/lib64/ld-2.17.so)
==2476==    by 0x4000E8D: do_preload (in /usr/lib64/ld-2.17.so)
==2476==    by 0x4004296: dl_main (in /usr/lib64/ld-2.17.so)
==2476==    by 0x4016244: _dl_sysdep_start (in /usr/lib64/ld-2.17.so)
==2476==  Uninitialised value was created by a stack allocation
==2476==    at 0x4004224: dl_main (in /usr/lib64/ld-2.17.so)
==2476==
==2476== Conditional jump or move depends on uninitialised value(s)
==2476==    at 0x4018577: index (in /usr/lib64/ld-2.17.so)
==2476==    by 0x40079D3: expand_dynamic_string_token (in /usr/lib64/ld-2.17.so)
==2476==    by 0x40084F5: _dl_map_object (in /usr/lib64/ld-2.17.so)
==2476==    by 0x400160D: map_doit (in /usr/lib64/ld-2.17.so)
==2476==    by 0x400F313: _dl_catch_error (in /usr/lib64/ld-2.17.so)
==2476==    by 0x4000E8D: do_preload (in /usr/lib64/ld-2.17.so)
==2476==    by 0x4004296: dl_main (in /usr/lib64/ld-2.17.so)
==2476==    by 0x4016244: _dl_sysdep_start (in /usr/lib64/ld-2.17.so)
==2476==  Uninitialised value was created by a stack allocation
==2476==    at 0x4004224: dl_main (in /usr/lib64/ld-2.17.so)
==2476==
0513-059 The FSRM Subsystem has been started. Subsystem PID is 2477.
==2476==
==2476== HEAP SUMMARY:
==2476==     in use at exit: 3,620 bytes in 3 blocks
==2476==   total heap usage: 40 allocs, 37 frees, 7,841 bytes allocated
==2476==
==2476== 528 bytes in 1 blocks are still reachable in loss record 1 of 3
==2476==    at 0x4C289EE: malloc (vg_replace_malloc.c:270)
==2476==    by 0x505015E: breakcrit (odmfind.c:434)
==2476==    by 0x5050BDB: raw_find_obj (odmfind.c:659)
==2476==    by 0x5058BBA: odm_get_obj (odmi.c:3019)
==2476==    by 0x4E39AF1: readrec (srcodm.c:110)
==2476==    by 0x4E3780A: cmdargs (cmdargs.c:364)
==2476==    by 0x400BEC: main (start.c:126)
==2476==
==2476== 1,288 bytes in 1 blocks are still reachable in loss record 2 of 3
==2476==    at 0x4C289EE: malloc (vg_replace_malloc.c:270)
==2476==    by 0x505B270: odm_mount_class (odmi.c:3867)
==2476==    by 0x50589E5: odm_get_obj (odmi.c:2981)
==2476==    by 0x4E39AF1: readrec (srcodm.c:110)
==2476==    by 0x4E3780A: cmdargs (cmdargs.c:364)
==2476==    by 0x400BEC: main (start.c:126)
==2476==
==2476== 1,804 bytes in 1 blocks are definitely lost in loss record 3 of 3
==2476==    at 0x4C289EE: malloc (vg_replace_malloc.c:270)
==2476==    by 0x505B27F: odm_mount_class (odmi.c:3868)
==2476==    by 0x50589E5: odm_get_obj (odmi.c:2981)
==2476==    by 0x4E39AF1: readrec (srcodm.c:110)
==2476==    by 0x4E3780A: cmdargs (cmdargs.c:364)
==2476==    by 0x400BEC: main (start.c:126)
==2476==
==2476== LEAK SUMMARY:
==2476==    definitely lost: 1,804 bytes in 1 blocks
==2476==    indirectly lost: 0 bytes in 0 blocks
==2476==      possibly lost: 0 bytes in 0 blocks
==2476==    still reachable: 1,816 bytes in 2 blocks
==2476==         suppressed: 0 bytes in 0 blocks
==2476==
==2476== For counts of detected and suppressed errors, rerun with: -v
==2476== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0)

Daemon name : FSRM
Memory leak introduced as :char* skg = (char*)malloc (10000*sizeof(char));


ThanksSampath S.

Re: [Valgrind-users] ARM - WARNING: Serious error when reading debug info

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

>  root$valgrind --tool=callgrind ./basic > out.txt

It is *always* a bad idea to run an application as root
unless the app requires elevated privileges.  DO NOT run valgrind as root.
Create and run as a real non-root user; consult your system documentation.

	<<snip>>
> ==2405== For interactive control, run 'callgrind_control -h'.
> --2405-- WARNING: Serious error when reading debug info
> --2405-- When reading debug info from /opt/valgrind/lib/valgrind/callgrind-arm-linux:
> --2405-- Missing or invalid ELF Section Header Table

Check if you get the same or similar message when running something other than callgrind.
Try  --tool=none  or  --tool=memcheck .

Inspect the file  /opt/valgrind/lib/valgrind/callgrind-arm-linux .
It should be a copy of some callgrind-x86-linux located within the build directory.
(It is common to run out of disk space on a machine where you are tempted
to run apps as the root user.)
What does the 'file' utility program say about callgrind-arm-linux?
Does "readelf --sections" give good output?

Compare /opt/valgrind/lib/valgrind/callgrind-arm-linux with callgrind-i686-linux
(because you say that it works on x86 ubutntu.)  Obviously the exact contents differ,
but other characteristics (size, owner, date, permissions, ...) should be similar.

Re: [Valgrind-users] Helgrind: Recursive Locing of normal mutex

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

On 25/02/15 06:05, SHEHAB ZAINELDINE wrote:

> That would mean, that locking the same lock twice in a row should
> trigger helgrind to stop the program and give me the error, but what
> happens is that the deadlock is allowed to happen. I there something
> that I am missing, or is that a bug?

Why do you think that is what "should" happen?

That is not how valgrind handles errors - it reports problems and then 
allows execution to continue.

Tom

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

Re: [Valgrind-users] ARM - WARNING: Serious error when reading debug info

[Raul G. <rau...@ma...>]

Hello Valgrind team,

Any comments on the issue I presented below? I am still unable to get useful data from Valgrind on ARM.

Regards,
Raul.

________________________________
From: Raul Garcia [rau...@ma...]
Sent: Thursday, February 19, 2015 9:06 PM
To: val...@li...
Subject: [Valgrind-users] ARM - WARNING: Serious error when reading debug info

Hello valgrind team,

I want to run valgrind on a ARM platform (Cortex A9) that is running Linaro. I managed to cross-compile valgrind for ARM:

root$valgrind --version
valgrind-3.10.1

Also, I succesfully compiled a program on this platform:

root$gcc -g basicmath_large.c rad2deg.c cubic.c isqrt.c -o basic -lm

Problem is, that when I try to use valgrind I get an error:

root$valgrind --tool=callgrind ./basic > out.txt
==2405== Callgrind, a call-graph generating cache profiler
==2405== Copyright (C) 2002-2013, and GNU GPL'd, by Josef Weidendorfer et al.
==2405== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==2405== Command: ./basic
==2405==
==2405== For interactive control, run 'callgrind_control -h'.
--2405-- WARNING: Serious error when reading debug info
--2405-- When reading debug info from /opt/valgrind/lib/valgrind/callgrind-arm-linux:
--2405-- Missing or invalid ELF Section Header Table
==2405==
==2405== Events    : Ir
==2405== Collected : 9239
==2405==
==2405== I   refs:      9,239
root$

According the the forums, this could be because "No symbols get loaded". Is there any way to solve this issue? is there a workaround for this?  Same procedure do works for me on a x86 platform running ubuntu.

Raul.

Re: [Valgrind-users] A great trick for counting cycles using callgrind - but what about massif?

[Josef W. <Jos...@gm...>]

Whether such a thing can be supported by a tool of course depends on the
tool.
For memcheck, this obviously makes no sense. But yes, it could become a
VG core
feature and tools enable it if they can cope with.
E.g. for lackey, it also would work.

To not forget about it, can you add it as "wishlist" bug report?

Josef


Am 22.02.2015 um 12:09 schrieb Peter Toft:
> Hi all
> 
> In order to count cycles for part of my C/C++ code I often use
> 
> 1. #include <valgrind/callgrind.h>
> 
> 2. add the following macros surrounding the blocks you wish to profile:
> 
> CALLGRIND_START_INSTRUMENTATION
> ..
> code I want to profile
> ..
> 
> CALLGRIND_STOP_INSTRUMENTATION
> 
> 3. valgrind --tool=callgrind --instr-atstart=no command
> 
> This is very nice - but a similar procedure/trick apparently does not 
> apply for massif.
> If I want to monitor memory for a part of the run-time, but not all.
> Have I missed something??
> 
> It could really be nice to have - so if possible, please add to the list 
> of future development ideas.
> I might be able to code some of this if I get some help on where to 
> start.
> 
> Best
> 

[Valgrind-users] A great trick for counting cycles using callgrind - but what about massif?

[Peter T. <pt...@li...>]

Hi all

In order to count cycles for part of my C/C++ code I often use

1. #include <valgrind/callgrind.h>

2. add the following macros surrounding the blocks you wish to profile:

CALLGRIND_START_INSTRUMENTATION
..
code I want to profile
..

CALLGRIND_STOP_INSTRUMENTATION

3. valgrind --tool=callgrind --instr-atstart=no command

This is very nice - but a similar procedure/trick apparently does not 
apply for massif.
If I want to monitor memory for a part of the run-time, but not all.
Have I missed something??

It could really be nice to have - so if possible, please add to the list 
of future development ideas.
I might be able to code some of this if I get some help on where to 
start.

Best

-- 
Peter Toft <pt...@li...>

Re: [Valgrind-users] Assertion 'DRD_(g_threadinfo)[tid].pt_threadid != INVALID_POSIX_THREADID' failed.

[Bart V. A. <bva...@ac...>]

On 02/21/15 01:08, Joe VanAndel wrote:
> I am using valgrind 3.10.1 (I get the same results building valgrind
> from SVN).  
> 
> My program uses boost 1_57_0, and Wt 3-3-4-rc1.  I am compiling with gcc
> 4.8.2 on CentOS 7.0.1406 
> 
> When I run my program under valgrind —tool=drd, 
> 
> valgrind aborts with the attached message.
> I have several questions:
> 
> 1) If this is a real error in my code, Wt, or Boost, how would I find
> and fix the error?
> 
> 2) Does anyone routinely use the boost DRD tool with Wt and Boost, or
> with Boost?
> 
> 
> drd: drd_thread.c:630 (vgDrd_thread_entering_pthread_create): Assertion
> 'DRD_(g_threadinfo)[tid].pt_threadid != INVALID_POSIX_THREADID' failed.
> 
> host stacktrace:
> ==21016==    at 0x38046C68: show_sched_status_wrk (m_libcassert.c:319)
> ==21016==    by 0x38046D84: report_and_quit (m_libcassert.c:390)
> ==21016==    by 0x38046F11: vgPlain_assert_fail (m_libcassert.c:456)
> ==21016==    by 0x3803639B: vgDrd_thread_entering_pthread_create
> (drd_thread.c:630)
> ==21016==    by 0x3802AC6B: handle_client_request (drd_clientreq.c:295)
> ==21016==    by 0x3805E1E0: wrap_tool_handle_client_request
> (m_tooliface.c:280)
> ==21016==    by 0x38097C9F: do_client_request (scheduler.c:2074)
> ==21016==    by 0x38097C9F: vgPlain_scheduler (scheduler.c:1407)
> ==21016==    by 0x380A687C: thread_wrapper (syswrap-linux.c:103)
> ==21016==    by 0x380A687C: run_a_thread_NORETURN (syswrap-linux.c:156)
> 
> sched status:
>   running_tid=1
> 
> Thread 1: status = VgTs_Runnable
> ==21016==    at 0x4C2F5B9: vgDrd_entering_pthread_create
> (drd_pthread_intercepts.c:331)
> ==21016==    by 0x4C2F5B9: pthread_create_intercept
> (drd_pthread_intercepts.c:484)
> ==21016==    by 0x4C2F5B9: pthread_create@* (drd_pthread_intercepts.c:501)
> ==21016==    by 0x5C14C38: boost::thread::start_thread_noexcept() (in
> /usr/local/boost_1_57_0/lib/libboost_thread-mt.so.1.57.0)
> ==21016==    by 0x6A6975: boost::thread::start_thread() (thread.hpp:179)

This might be a bug in the Valgrind core. When a thread is created the
Valgrind core invokes drd_pre_thread_create(). That function calls
DRD_(thread_pre_create)() which sets up the valgrind-to-DRD thread ID
translation. The assertion failure above means that such a translation
had not been set up before the code in the newly created thread started
to run.

If you can provide a small test program with which I can reproduce the
above behavior I will have a look into this. The boost regression test
that is present in the Valgrind source tree seems to work fine on CentOS
7.0.1046:

$ ./vg-in-place --tool=drd drd/tests/boost_thread
==24662== drd, a thread error detector
==24662== Copyright (C) 2006-2013, and GNU GPL'd, by Bart Van Assche.
==24662== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for
copyright info
==24662== Command: drd/tests/boost_thread
==24662==
Thread 1.
Thread 2.
Finished.
==24662==
==24662== For counts of detected and suppressed errors, rerun with: -v
==24662== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 33 from 33)

Bart.

[Valgrind-users] Assertion 'DRD_(g_threadinfo)[tid].pt_threadid != INVALID_POSIX_THREADID' failed.

[Joe V. <van...@uc...>]

I am using valgrind 3.10.1 (I get the same results building valgrind from
SVN).

My program uses boost 1_57_0, and Wt 3-3-4-rc1.  I am compiling with gcc
4.8.2 on CentOS 7.0.1406

When I run my program under valgrind —tool=drd,

valgrind aborts with the attached message.
I have several questions:

1) If this is a real error in my code, Wt, or Boost, how would I find and
fix the error?

2) Does anyone routinely use the boost DRD tool with Wt and Boost, or with
Boost?


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

host stacktrace:
==21016==    at 0x38046C68: show_sched_status_wrk (m_libcassert.c:319)
==21016==    by 0x38046D84: report_and_quit (m_libcassert.c:390)
==21016==    by 0x38046F11: vgPlain_assert_fail (m_libcassert.c:456)
==21016==    by 0x3803639B: vgDrd_thread_entering_pthread_create
(drd_thread.c:630)
==21016==    by 0x3802AC6B: handle_client_request (drd_clientreq.c:295)
==21016==    by 0x3805E1E0: wrap_tool_handle_client_request
(m_tooliface.c:280)
==21016==    by 0x38097C9F: do_client_request (scheduler.c:2074)
==21016==    by 0x38097C9F: vgPlain_scheduler (scheduler.c:1407)
==21016==    by 0x380A687C: thread_wrapper (syswrap-linux.c:103)
==21016==    by 0x380A687C: run_a_thread_NORETURN (syswrap-linux.c:156)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==21016==    at 0x4C2F5B9: vgDrd_entering_pthread_create
(drd_pthread_intercepts.c:331)
==21016==    by 0x4C2F5B9: pthread_create_intercept
(drd_pthread_intercepts.c:484)
==21016==    by 0x4C2F5B9: pthread_create@* (drd_pthread_intercepts.c:501)
==21016==    by 0x5C14C38: boost::thread::start_thread_noexcept() (in
/usr/local/boost_1_57_0/lib/libboost_thread-mt.so.1.57.0)
==21016==    by 0x6A6975: boost::thread::start_thread() (thread.hpp:179)
==21016==    by 0x8E48455:
boost::thread::thread<boost::_bi::bind_t<unsigned long,
boost::_mfi::mf0<unsigned long, boost::asio::io_service>,
boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> > >
>(boost::_bi::bind_t<unsigned long, boost::_mfi::mf0<unsigned long,
boost::asio::io_service>,
boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> > >,
boost::disable_if_c<boost::thread_detail::is_rv<boost::_bi::bind_t<unsigned
long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>,
boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> > > >::value,
boost::thread::dummy*>::type) (in
/usr/local/boost_1_57_0/wt-3.3.4/lib/libwtclasses.so.1.4.0)
==21016==    by 0x8E44901: boost::thread*
boost::thread_group::create_thread<boost::_bi::bind_t<unsigned long,
boost::_mfi::mf0<unsigned long, boost::asio::io_service>,
boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> > >
>(boost::_bi::bind_t<unsigned long, boost::_mfi::mf0<unsigned long,
boost::asio::io_service>,
boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> > >) (in
/usr/local/boost_1_57_0/wt-3.3.4/lib/libwtclasses.so.1.4.0)
==21016==    by 0x8E412DA: Wt::Wc::WcIoService::WcIoService() (in
/usr/local/boost_1_57_0/wt-3.3.4/lib/libwtclasses.so.1.4.0)
==21016==    by 0x8E3B22F: __static_initialization_and_destruction_0(int,
int) (in /usr/local/boost_1_57_0/wt-3.3.4/lib/libwtclasses.so.1.4.0)
==21016==    by 0x8E3B483: _GLOBAL__sub_I_util.cpp (in
/usr/local/boost_1_57_0/wt-3.3.4/lib/libwtclasses.so.1.4.0)
==21016==    by 0x400F502: call_init (dl-init.c:82)
==21016==    by 0x400F502: _dl_init (dl-init.c:131)
==21016==    by 0x4001459: ??? (in /usr/lib64/ld-2.17.so)


-- 
Joe VanAndel
NCAR/EOL