valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Dirty helper called more times than expected

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

Am 04.10.2013 21:47, schrieb Sonny Tavernier:
> Hi, 
> 
> I have an unexpected behavior with a basic tool. 
> For each Put statement of a basic block, I register a dirty helper using
> unsafeIRDirty_0_N. 
> The problem is that the dirty helper is called more times than expected, 
> e.g. there are 5 Put statements in a basic block but the dirty helper is
> called 13 times.

You seem to confuse instrumentation vs. execution time.

As you set the counters to zero only at instrumentation time, of course
they will diverge when a BB is executed a second time (as every BB is
instrumented only once).

Further, Valgrind works on super blocks (SBs), not just BBs.
A SB may have multiple side exits. Thus, counters may be
different whenever the execution flow exits an SB early.

Josef

Re: [Valgrind-users] Valgrind + Android

[Marc S. <mar...@gm...>]

Yep. "am start" sends a signal via socket to zygote, so there's no children
to follow.


2013/10/5 Vasily Golubev <vas...@gm...>

> Mr. Sampe,
>
> Did you try flag --trace-children=yes?
>
> Vasily
>
> On Thu, Oct 3, 2013 at 4:19 PM, Marc Sampé <mar...@es...>
> wrote:
> > Hi!
> >
> > I'm new using Valgrind out of Linux. I'm working in a project on Android
> and
> > I'm trying to instrument "com.android.mms" or Mms.apk.
> >
> > I tried using "am start" but am only sends a signal to Zygote so valgrind
> > will never trace the new process.
> >
> > I read that Valgrind has ARM support, so I guess that someone knows hot
> to
> > do it.
> >
> > Any hint or help will be grateful!
> >
> > Thanks
> >
> > --
> > Marc Sampé Gascó
> > Estudiant de Enginyeria Informàtica ( UPC )
> >
> >
> ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> > from
> > the latest Intel processors and coprocessors. See abstracts and register
> >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
>
>
>
> --
> Best Regards,
> Vasily
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>



-- 
Marc

Re: [Valgrind-users] Valgrind + Android

[Vasily G. <vas...@gm...>]

Mr. Sampe,

Did you try flag --trace-children=yes?

Vasily

On Thu, Oct 3, 2013 at 4:19 PM, Marc Sampé <mar...@es...> wrote:
> Hi!
>
> I'm new using Valgrind out of Linux. I'm working in a project on Android and
> I'm trying to instrument "com.android.mms" or Mms.apk.
>
> I tried using "am start" but am only sends a signal to Zygote so valgrind
> will never trace the new process.
>
> I read that Valgrind has ARM support, so I guess that someone knows hot to
> do it.
>
> Any hint or help will be grateful!
>
> Thanks
>
> --
> Marc Sampé Gascó
> Estudiant de Enginyeria Informàtica ( UPC )
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>



-- 
Best Regards,
Vasily

Re: [Valgrind-users] Does 3.8.1 support armv5

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

> Has "https://bugs.kde.org/show_bug.cgi?id=248998 ARMv5 and v6 support"  been incorporated into release 3.8.1 so that support is now available for ARMv5 and ARMv6.

No.  ARMv7 is the minimum.  ARMv5/v6 is not supported by 3.8.1,
and probably will not be supported for a long time.
ARMv5 lacks reasonable hardware instruction support for threads.
Making threads work on ARMv5 is possible, but too cumbersome.
There are other things to work on that have larger payoff for the effort.
Patches which support memcheck for a single-threaded process on ARMv5
were submitted but not incorporated into the codebase for valgrind.

-- 

[Valgrind-users] Does 3.8.1 support armv5

[Lerner, D. <dav...@wi...>]

Some regression tests don't compile with gcc version 4.8.1 (GCC) using the armv5 switches 
-march=armv5te -marm -mthumb-interwork.  

The first to fail is atomic_incs.c which reports for example:
	Error: selected processor does not support ARM mode `ldrexb r8,[r9]'
	Error: selected processor does not support ARM mode `strexb r4,r8,[r9]'
...
The ARM instruction ldrex was added introduced with v6.  

A grep found ldrex references in VEX/priv/(host_arm_defs.c host_arm_isel.c host_arm_defs.c).

Has "https://bugs.kde.org/show_bug.cgi?id=248998 ARMv5 and v6 support"  been incorporated into release 3.8.1 so that support is now available for ARMv5 and ARMv6.  Or will execution on an ARMv5 target crash with SIGILL due to execution of the unimplemented instructions.  I'm seeing another valgrind early failure on the target but don't want to try and debug (or note) that failure if ARMv5 is not officially supported.

Dave

[Valgrind-users] Dirty helper called more times than expected

[Sonny T. <son...@gm...>]

Hi,

I have an unexpected behavior with a basic tool.
For each Put statement of a basic block, I register a dirty helper using
unsafeIRDirty_0_N.
The problem is that the dirty helper is called more times than expected,
e.g. there are 5 Put statements in a basic block but the dirty helper is
called 13 times.
I need to use dirty helpers in my tool but I am stuck for now, any help
would be very appreciated.

Here is the code:

unsigned int g_Put_cnt; // the number of Put statements in the basic block
unsigned int g_helper_Put_cnt; // the number of times helper_Put() was
called

static VG_REGPARM(0) void helper_print_counters()
{
    VG_(printf)("g_Put_cnt: %d - g_helper_Put_cnt: %d (%d)\n", g_Put_cnt,
g_helper_Put_cnt, g_helper_Put_cnt-g_Put_cnt);
}

static VG_REGPARM(0) void helper_Put()
{
    g_helper_Put_cnt++;
}

static
IRSB* fz_instrument ( VgCallbackClosure* closure,
                      IRSB* sb_in,
                      VexGuestLayout* layout,
                      VexGuestExtents* vge,
                      IRType gWordTy, IRType hWordTy )
{
    IRSB* sb_out;
    Int i;

    if (gWordTy != hWordTy) {
        /* We don't currently support this case. */
        VG_(tool_panic)("host/guest word size mismatch");
    }

    /* Set up sb_out */
    sb_out = deepCopyIRSBExceptStmts(sb_in);

    // Copy verbatim any IR preamble preceding the first IMark
    i = 0;
    while (i < sb_in->stmts_used && sb_in->stmts[i]->tag != Ist_IMark) {
        addStmtToIRSB(sb_out, sb_in->stmts[i]);
        i++;
    }

    g_Put_cnt = 0;
    g_helper_Put_cnt = 0;

    for (/*use current i*/; i < sb_in->stmts_used; i++)
    {
        IRStmt* st = sb_in->stmts[i];
        IRDirty* di;

        if (!st)
            continue;

        switch (st->tag)
        {
            case Ist_Put:
                di = unsafeIRDirty_0_N(0,
                                       "helper_Put",
                                       VG_(fnptr_to_fnentry)(&helper_Put),
                                       mkIRExprVec_0());
                addStmtToIRSB(sb_out, IRStmt_Dirty(di));

                g_Put_cnt++;
                break;
        }

        addStmtToIRSB(sb_out, st);
    }

    IRDirty* di = unsafeIRDirty_0_N(0, "helper_print_counters",
VG_(fnptr_to_fnentry)(&helper_print_counters), mkIRExprVec_0());
    addStmtToIRSB(sb_out, IRStmt_Dirty(di));

    return sb_out;
}

And the output:

g_Put_cnt: 22 - g_helper_Put_cnt: 22 (0)
g_Put_cnt: 21 - g_helper_Put_cnt: 21 (0)
g_Put_cnt: 8 - g_helper_Put_cnt: 8 (0)
g_Put_cnt: 5 - g_helper_Put_cnt: 13 (8)
g_Put_cnt: 5 - g_helper_Put_cnt: 18 (13)
g_Put_cnt: 6 - g_helper_Put_cnt: 6 (0)
g_Put_cnt: 6 - g_helper_Put_cnt: 6 (0)
g_Put_cnt: 9 - g_helper_Put_cnt: 9 (0)
g_Put_cnt: 9 - g_helper_Put_cnt: 22 (13)
g_Put_cnt: 9 - g_helper_Put_cnt: 35 (26)
g_Put_cnt: 9 - g_helper_Put_cnt: 48 (39)
g_Put_cnt: 9 - g_helper_Put_cnt: 61 (52)
g_Put_cnt: 9 - g_helper_Put_cnt: 74 (65)
g_Put_cnt: 9 - g_helper_Put_cnt: 87 (78)
g_Put_cnt: 9 - g_helper_Put_cnt: 100 (91)
g_Put_cnt: 9 - g_helper_Put_cnt: 113 (104)
g_Put_cnt: 9 - g_helper_Put_cnt: 126 (117)
g_Put_cnt: 9 - g_helper_Put_cnt: 139 (130)
g_Put_cnt: 9 - g_helper_Put_cnt: 152 (143)
g_Put_cnt: 9 - g_helper_Put_cnt: 157 (148)
...

Thank you in advance.

[Valgrind-users] Valgrind + Android

[Marc S. <mar...@es...>]

Hi!

I'm new using Valgrind out of Linux. I'm working in a project on Android
and I'm trying to instrument "com.android.mms" or Mms.apk.

I tried using "am start" but am only sends a signal to Zygote so valgrind
will never trace the new process.

I read that Valgrind has ARM support, so I guess that someone knows hot to
do it.

Any hint or help will be grateful!

Thanks

-- 
Marc Sampé Gascó
Estudiant de Enginyeria Informàtica ( UPC )

Re: [Valgrind-users] Is it possible to check specified bugs?

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

On Tue, 2013-10-01 at 15:33 +0400, Konstantin Serebryany wrote:

> 
> On Mon, Sep 30, 2013 at 11:22 PM, Philippe Waroquiers
> <phi...@sk...> wrote:

>         
>         > To my knowledge, Address sanitizer does not detect mismatch 
>         > between alloc and free fn
> 
> 
> It does:
Oops, yes. My theoretical knowledge stopped at
http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer
I did not look at the flags section.

Philippe

Re: [Valgrind-users] Is it possible to check specified bugs?

[Konstantin S. <kon...@gm...>]

On Mon, Sep 30, 2013 at 11:22 PM, Philippe Waroquiers <
phi...@sk...> wrote:

> On Mon, 2013-09-30 at 14:49 +0400, Konstantin Tokarev wrote:
> > 30.09.2013, 03:15, "Lu Mitnick" <kin...@gm...>:
> > > Hello all,
> > >
> > > Memcheck could be used to detect different type of bugs:
> > > 1. illegal read/write
> > > 2. use of uninitialised values
> > > 3. illegal frees
> > > 4. when a heap block is freed with an inappropriate deallocation
> function
> > > ...
> > >
> > > I am wondering whether it is possible to use valgrind to check
> specified bug types? In other words, I would like to use memcheck to only
> check addressable bug, illegal frees bug and allocation/deallocation
> routine mismatched bug in the first run. Then check the use of
> uninitialised values bug in the second run.
> What is the reason to do two runs rather than one single run (reporting
> all found problems) ?
>
> > >
> > > Thanks a lot.
> >
> > You can use AddressSanitizer (clang 3.0+ or gcc 4.8+) for the first run.
> As a bonus point it does not cause so heavy
> >  slowdown as valgrind and provides more verbose info for bugs like use
> after free (trace when it was allocated,
> > when it was deleted, and when it was used, while memcheck shows only the
> last one).
> Valgrind 3.8.1 (and before) gives the stack traces of the
> 'use after free' and and where it was freed.
>
> In Valgrind 3.9.0 SVN, the option
>    --keep-stacktraces=alloc|free|alloc-and-free|alloc-then-free|none
>         stack trace(s) to keep for malloc'd/free'd areas
> [alloc-then-free]
> allows to specify what to keep, giving e.g.
>
> ==2495== Invalid write of size 1
> ==2495==    at 0x804844A: really (malloc1.c:20)
> ==2495==    by 0x80483FE: main (malloc1.c:9)
> ==2495==  Address 0x4028029 is 1 bytes inside a block of size 10 free'd
> ==2495==    at 0x4006CC2: free (vg_replace_malloc.c:468)
> ==2495==    by 0x8048443: really (malloc1.c:19)
> ==2495==    by 0x80483FE: main (malloc1.c:9)
> ==2495==   block was alloc'd at
> ==2495==    at 0x40072D5: malloc (vg_replace_malloc.c:291)
> ==2495==    by 0x8048419: really (malloc1.c:16)
> ==2495==    by 0x80483FE: main (malloc1.c:9)
>
> Otherwise, the option --undef-value-errors=no|yes allows to disable/enable
> checking
> for undef values. --undef-value-errors=no more or less doubles the speed
> (measured on bz2 on x86-64).
>
> To my knowledge, Address sanitizer does not detect mismatch between alloc
> and free fn
>

It does:
% cat  malloc_delete_mismatch.cc
#include <stdlib.h>
static volatile char *x;
int main() {
  x = (char*)malloc(10);
  x[0] = 0;
  delete x;
}
% clang++ -g malloc_delete_mismatch.cc -fsanitize=address && ./a.out
=================================================================
==416==ERROR: AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator
delete) on 0x60200000eff0
    #0 0x4450b6 in operator delete(void*)
/home/kcc/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:83
    #1 0x4588c7 in main /tmp/malloc_delete_mismatch.cc:6
    #2 0x7f586d9c676c in __libc_start_main
/build/buildd/eglibc-2.15/csu/libc-start.c:226
0x60200000eff0 is located 0 bytes inside of 10-byte region
[0x60200000eff0,0x60200000effa)
allocated by thread T0 here:
    #0 0x4446c6 in malloc
/home/kcc/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:74
    #1 0x458849 in main /tmp/malloc_delete_mismatch.cc:4
    #2 0x7f586d9c676c in __libc_start_main
/build/buildd/eglibc-2.15/csu/libc-start.c:226
SUMMARY: AddressSanitizer: alloc-dealloc-mismatch
/home/kcc/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:83 operator
delete(void*)
==416==HINT: if you don't care about these warnings you may set
ASAN_OPTIONS=alloc_dealloc_mismatch=0
==416==ABORTING
% g++ malloc_delete_mismatch.cc -fsanitize=address -static-libasan &&
./a.out
=================================================================
==596==ERROR: AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator
delete) on 0x60200000eff0
    #0 0x4397ec in operator delete(void*) (/tmp/a.out+0x4397ec)
    #1 0x44bf15 in main (/tmp/a.out+0x44bf15)
    #2 0x7f993e15476c in __libc_start_main
/build/buildd/eglibc-2.15/csu/libc-start.c:226
0x60200000eff0 is located 0 bytes inside of 10-byte region
[0x60200000eff0,0x60200000effa)
allocated by thread T0 here:
    #0 0x438ce4 in malloc (/tmp/a.out+0x438ce4)
    #1 0x44bec1 in main (/tmp/a.out+0x44bec1)
    #2 0x7f993e15476c in __libc_start_main
/build/buildd/eglibc-2.15/csu/libc-start.c:226
SUMMARY: AddressSanitizer: alloc-dealloc-mismatch ??:0 operator
delete(void*)
==596==HINT: if you don't care about these warnings you may set
ASAN_OPTIONS=alloc_dealloc_mismatch=0
==596==ABORTING
%



> (which memcheck does) but it finds overruns in stack and global vars
>

true. :)

Of course, AddressSanitizer remains blind to uninits.

--kcc


>
> Philippe
>
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
>

Re: [Valgrind-users] Helgrind bug? Pointer retained after free?

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

On Mon, 2013-09-30 at 15:25 +0000, Phil Longstaff wrote:
> I just got the following report:
> 
> ==83343== Possible data race during read of size 2 at 0xA38C41A by
> thread #2
> 
> ==83343== Locks held: 3, at addresses 0x2ED6EA0 0x999FD38 0xA389AB8
> 
> ==83343==    at 0x62911E7: strcpy (in /lib/libc.so.7)
> 
> ==83343==    by 0x1F52C97: spr_socket_get_addr (spr_socket.c:87)
> 
> ==83343==    by 0x1F4D787:
> spr_evsportnw_sync_connect_ready_event_handler (spr_evsportnw.c:507)
> 
> ==83343==    by 0x1F4C48C: spr_evsdisp_dispatch (spr_evsdisp.c:736)
> 
> ==83343==    by 0x1F601C7: io_connection_connect (ioc.c:629)
> 
> ==83343==
> 
> ==83343== This conflicts with a previous write of size 8 by thread #47
> 
> ==83343== Locks held: 3, at addresses 0x63E4308 0x8B97D50 0x6FA5420
> 
> ==83343==    at 0x629717C: __sys_read (in /lib/libc.so.7)
> 
> ==83343==    by 0x6296BFF: __sread (in /lib/libc.so.7)
> 
> ==83343==    by 0x6296952: _sread (in /lib/libc.so.7)
> 
> ==83343==    by 0x627FF35: __srefill (in /lib/libc.so.7)
> 
> ==83343==    by 0x6263B83: __svfscanf (in /lib/libc.so.7)
> 
> ==83343==    by 0x6262C88: fscanf (in /lib/libc.so.7)
> 
> ==83343==    by 0x1BFD4BB: doModuleMapping(unsigned int, int*, bool)
> (hardware.cpp:406)
> 
>  
> 
> The code in spr_socket.c is:
> 
>   char * _this_addr;
> 
>   char * t = …;
> 
>  
> 
>   _this_addr = strcpy((char*)malloc(strlen(t)+1),t);
> 
>   sprintf(r,"%s",_this_addr);                                ç This is
> line 87
The stack trace of the error above shows a call to strcpy, not a call to
sprintf ?
Are you sure the read problem is not caused by reading bytes behind
char *t as part of the strcpy call ?

> 
>   free(_this_addr);
> 
>  
> 
> So, it’s complaining about a read from memory which has been newly
> malloc’ed.  Bug?  Could the other piece of code this has a conflict
> with still be holding on to it and therefore helgrind hasn’t cleared
> its history for these bytes in the heap?
> 
>  
> 
> This is with valgrind 3.8.0 on freebsd.
If the code works on linux, maybe double check on a linux system ?
And/or double check with drd ?

Philippe

Re: [Valgrind-users] Is it possible to check specified bugs?

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

On Mon, 2013-09-30 at 14:49 +0400, Konstantin Tokarev wrote:
> 30.09.2013, 03:15, "Lu Mitnick" <kin...@gm...>:
> > Hello all,
> >
> > Memcheck could be used to detect different type of bugs:
> > 1. illegal read/write
> > 2. use of uninitialised values
> > 3. illegal frees
> > 4. when a heap block is freed with an inappropriate deallocation function
> > ...
> >
> > I am wondering whether it is possible to use valgrind to check specified bug types? In other words, I would like to use memcheck to only check addressable bug, illegal frees bug and allocation/deallocation routine mismatched bug in the first run. Then check the use of uninitialised values bug in the second run.
What is the reason to do two runs rather than one single run (reporting
all found problems) ?

> >
> > Thanks a lot.
> 
> You can use AddressSanitizer (clang 3.0+ or gcc 4.8+) for the first run. As a bonus point it does not cause so heavy
>  slowdown as valgrind and provides more verbose info for bugs like use after free (trace when it was allocated, 
> when it was deleted, and when it was used, while memcheck shows only the last one).
Valgrind 3.8.1 (and before) gives the stack traces of the
'use after free' and and where it was freed.

In Valgrind 3.9.0 SVN, the option 
   --keep-stacktraces=alloc|free|alloc-and-free|alloc-then-free|none
        stack trace(s) to keep for malloc'd/free'd areas       [alloc-then-free]
allows to specify what to keep, giving e.g.

==2495== Invalid write of size 1
==2495==    at 0x804844A: really (malloc1.c:20)
==2495==    by 0x80483FE: main (malloc1.c:9)
==2495==  Address 0x4028029 is 1 bytes inside a block of size 10 free'd
==2495==    at 0x4006CC2: free (vg_replace_malloc.c:468)
==2495==    by 0x8048443: really (malloc1.c:19)
==2495==    by 0x80483FE: main (malloc1.c:9)
==2495==   block was alloc'd at
==2495==    at 0x40072D5: malloc (vg_replace_malloc.c:291)
==2495==    by 0x8048419: really (malloc1.c:16)
==2495==    by 0x80483FE: main (malloc1.c:9)

Otherwise, the option --undef-value-errors=no|yes allows to disable/enable checking
for undef values. --undef-value-errors=no more or less doubles the speed
(measured on bz2 on x86-64).

To my knowledge, Address sanitizer does not detect mismatch between alloc and free fn
(which memcheck does) but it finds overruns in stack and global vars

Philippe

[Valgrind-users] Helgrind bug? Pointer retained after free?

[Phil L. <plo...@sa...>]

I just got the following report:
==83343== Possible data race during read of size 2 at 0xA38C41A by thread #2
==83343== Locks held: 3, at addresses 0x2ED6EA0 0x999FD38 0xA389AB8
==83343==    at 0x62911E7: strcpy (in /lib/libc.so.7)
==83343==    by 0x1F52C97: spr_socket_get_addr (spr_socket.c:87)
==83343==    by 0x1F4D787: spr_evsportnw_sync_connect_ready_event_handler (spr_evsportnw.c:507)
==83343==    by 0x1F4C48C: spr_evsdisp_dispatch (spr_evsdisp.c:736)
==83343==    by 0x1F601C7: io_connection_connect (ioc.c:629)
==83343==
==83343== This conflicts with a previous write of size 8 by thread #47
==83343== Locks held: 3, at addresses 0x63E4308 0x8B97D50 0x6FA5420
==83343==    at 0x629717C: __sys_read (in /lib/libc.so.7)
==83343==    by 0x6296BFF: __sread (in /lib/libc.so.7)
==83343==    by 0x6296952: _sread (in /lib/libc.so.7)
==83343==    by 0x627FF35: __srefill (in /lib/libc.so.7)
==83343==    by 0x6263B83: __svfscanf (in /lib/libc.so.7)
==83343==    by 0x6262C88: fscanf (in /lib/libc.so.7)
==83343==    by 0x1BFD4BB: doModuleMapping(unsigned int, int*, bool) (hardware.cpp:406)

The code in spr_socket.c is:
  char * _this_addr;
  char * t = ...;

  _this_addr = strcpy((char*)malloc(strlen(t)+1),t);
  sprintf(r,"%s",_this_addr);                                 <== This is line 87
  free(_this_addr);

So, it's complaining about a read from memory which has been newly malloc'ed.  Bug?  Could the other piece of code this has a conflict with still be holding on to it and therefore helgrind hasn't cleared its history for these bytes in the heap?

This is with valgrind 3.8.0 on freebsd.

Phil
-----
Phil Longstaff
Senior Software Engineer
x2904

Re: [Valgrind-users] Is it possible to check specified bugs?

[Konstantin T. <an...@ya...>]

30.09.2013, 03:15, "Lu Mitnick" <kin...@gm...>:
> Hello all,
>
> Memcheck could be used to detect different type of bugs:
> 1. illegal read/write
> 2. use of uninitialised values
> 3. illegal frees
> 4. when a heap block is freed with an inappropriate deallocation function
> ...
>
> I am wondering whether it is possible to use valgrind to check specified bug types? In other words, I would like to use memcheck to only check addressable bug, illegal frees bug and allocation/deallocation routine mismatched bug in the first run. Then check the use of uninitialised values bug in the second run.
>
> Thanks a lot.

You can use AddressSanitizer (clang 3.0+ or gcc 4.8+) for the first run. As a bonus point it does not cause so heavy slowdown as valgrind and provides more verbose info for bugs like use after free (trace when it was allocated, when it was deleted, and when it was used, while memcheck shows only the last one).


-- 
Regards,
Konstantin

Re: [Valgrind-users] Memcheck does not report any error

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

On 30/09/13 08:59, Damien R wrote:

> Thanks to everyone who answered the question but I still do not
> understand why foo->print() does work. For me foo is part of the object
> because it is the object. Does it mean that the method print is
> generated like:
> void print(Foo *)
> {
>      std::cout << "foo" << std::endl;
> }

Yes, basically that is exactly what happens. The function (with g++) is 
actually called _ZN3Foo5printEv but other than that you have the details 
exactly right.

> If this is the case, can someone give me some resources about the memory
> organisation of c++ and about class/methods generation?

Well strictly speaking those are implementation details which may vary 
from one compiler to another, or at least from one platform to another.

Tom

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

Re: [Valgrind-users] Memcheck does not report any error

[Damien R <dam...@gm...>]

On 09/29/2013 02:22 PM, Tom Hughes wrote:
> Yes. Nothing in the "foo->print()" call actually accesses any memory
> that was part of the object.
>
> The body of the function doesn't access any member variables, and it's
> not a virtual function so the vtable is not read, so there is no
> access to any freed memory.
>
> Tom
>
Thanks to everyone who answered the question but I still do not
understand why foo->print() does work. For me foo is part of the object
because it is the object. Does it mean that the method print is
generated like:
void print(Foo *)
{
    std::cout << "foo" << std::endl;
}

If this is the case, can someone give me some resources about the memory
organisation of c++ and about class/methods generation?

Regards,
Damien R.

[Valgrind-users] Is it possible to check specified bugs?

[Lu M. <kin...@gm...>]

Hello all,

Memcheck could be used to detect different type of bugs:
1. illegal read/write
2. use of uninitialised values
3. illegal frees
4. when a heap block is freed with an inappropriate deallocation function
...

I am wondering whether it is possible to use valgrind to check specified
bug types? In other words, I would like to use memcheck to only check
addressable bug, illegal frees bug and allocation/deallocation routine
mismatched bug in the first run. Then check the use of uninitialised values
bug in the second run.

Thanks a lot.

Re: [Valgrind-users] Memcheck does not report any error

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

On 29/09/13 12:16, Damien R wrote:

> I am using valgrind 3.7.0 and with the following program, valgrind
> reports no error.
>
> #include <iostream>
>
> struct Foo
> {
>    void print()
>    {
>      std::cout << "foo" << std::endl;
>    }
> };
>
> int main()
> {
>    Foo * foo = new Foo;
>    delete foo;
>    foo->print();
>    return 0;
> }
>
> Can someone explain why valgrind does not report any error?

Yes. Nothing in the "foo->print()" call actually accesses any memory 
that was part of the object.

The body of the function doesn't access any member variables, and it's 
not a virtual function so the vtable is not read, so there is no access 
to any freed memory.

Tom

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

Re: [Valgrind-users] Memcheck does not report any error

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

On Sun, 2013-09-29 at 13:16 +0200, Damien R wrote:
> Hi,
> 
> 
> I am using valgrind 3.7.0 and with the following program, valgrind
> reports no error.
> 
> 
> #include <iostream>
> 
> struct Foo
> {
>   void print()
>   {
>     std::cout << "foo" << std::endl;
>   }
> };
> 
> int main()
> {
>   Foo * foo = new Foo;
>   delete foo;
>   foo->print();
>   return 0;
> }
> 
> 
> Can someone explain why valgrind does not report any error?
The compiler inserts a call to foo print, but this does not
imply a dereference of foo pointer. If you add int a
in Foo, and assigns a value to a inside print, then you get an error.

Philippe

Re: [Valgrind-users] Memcheck does not report any error

[Matthias S. <zz...@ge...>]

On 29.09.2013 13:16, Damien R wrote:
> Hi,
>
> I am using valgrind 3.7.0 and with the following program, valgrind 
> reports no error.
>
> #include <iostream>
>
> struct Foo
> {
>   void print()
>   {
>     std::cout << "foo" << std::endl;
>   }
> };
>
> int main()
> {
>   Foo * foo = new Foo;
>   delete foo;
>   foo->print();
>   return 0;
> }
>
> Can someone explain why valgrind does not report any error?
>
Hi!

You call Foo::print() on a deleted instance of Foo, but this method does 
not access any data from inside Foo and is no virtual method.
So nothing happens, that valgrind should complain about.

Regards
Matthias

[Valgrind-users] Memcheck does not report any error

[Damien R <dam...@gm...>]

Hi,

I am using valgrind 3.7.0 and with the following program, valgrind reports
no error.

#include <iostream>

struct Foo
{
  void print()
  {
    std::cout << "foo" << std::endl;
  }
};

int main()
{
  Foo * foo = new Foo;
  delete foo;
  foo->print();
  return 0;
}

Can someone explain why valgrind does not report any error?

Regards,
Damien R.

Re: [Valgrind-users] FW: Helgrind to-do list

[David F. <fa...@kd...>]

On Friday 27 September 2013 17:51:19 Phil Longstaff wrote:
> > From: David Faure [mailto:fa...@kd...]
> > Sent: Friday, September 27, 2013 11:18 AM
> > To: Phil Longstaff
> > Cc: val...@li...
> > Subject: Re: [Valgrind-users] FW: Helgrind to-do list
> > 
> > On Friday 27 September 2013 15:01:54 Phil Longstaff wrote:
> > > I was thinking about this one last night, and it's trickier than I
> > > first thought.
> > > 
> > > L = lock, T = trylock
> > > Thread1: L1 L2
> > > Thread2: L2 T1
> > > 
> > > Not a deadlock because the trylock will just fail.  However, suppose
> > > we
> > > have:
> > > 
> > > Thread1: L1 L2
> > > Thread2: L2 T1
> > > 
> > > And then later:
> > > 
> > > Thread 3: L1 L2
> > > 
> > > When helgrind handles L2, it would already find the graph edge L1 ->
> > > L2 so wouldn't it just return since that is the "correct order"?
> > > David sent me some past e-mail and I saw some comments about putting
> > > lock vs trylock into the graph.  Seems to me that when processing T2,
> > > helgrind would not report a problem, but would add the T2 -> L1 link,
> > > and would also need to ensure that if L1 -> L2 happens in the future, it
> > > is reported.> 
> > A failing trylock cannot create a dead lock.
> > Only a succesful one, can.
> > 
> > So the question is whether we can assume a failed trylock could have
> > succeeded in creating a deadlock if it hadn't failed. In your particular
> > example, we can.
> > In many other cases, we can't know that "what happened after the failed
> > trylock" would have happened too, if it had succeded. There could be an
> > if() statement :-)
> > 
> > So IMHO it's much easier to just drop failed trylocks and only remember
> > successful ones, but yes, one can refine that for the case above, i.e.
> > when the failed-trylock is the last thing in the chain.
> > 
> > If anything happens *after* a failed trylock, then one can't store a
> > "T1 -> anything" link.
> 
> I agree.  My question is what we should store after a *successful* trylock.
> 
> Suppose helgrind sees these threads:
> 
> Thr1: L1   L2
> 
> So, it should add L1 -> L2 to the graph
> 
> Thr2: L1  L2
> 
> Assume thr1 has unlocked both L1 and L2.  Since L1 -> L2 already exists,
> does helgrind do anything?

Surely not, since L1 -> L2 is already there?

> Thr3: L2  T1 (unsuccessful)
> 
> No deadlock can occur, no edge should be added, no report.

Right.

> Thr3: L2 T1 (successful)
> 
> So, is your suggestion that L2 -> L1 should be added here, should be
> indistinguishable from L1 -> L2 added previously, and that the report
> should happen here, even though this operation would not be the one that
> causes the deadlock?

You're right. The whole point of trylock is to not deadlock :)
What thread 3 is doing, is valid.

The difference between "L2 L1" and "L2 T1(successful)" is that the first one 
should lead to a report and the second one shouldn't.
But once that step is done, in both cases we want L2 -> L1 in the graph.

So that
Thr 1: L2 T1 (successful)
Thr 2: L1 L2 (after thread 1)
gives a report of wrong lock order.

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

Re: [Valgrind-users] FW: Helgrind to-do list

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

On Fri, 2013-09-27 at 15:01 +0000, Phil Longstaff wrote:
> I was thinking about this one last night, and it's trickier than I first thought.
> 
> L = lock, T = trylock
> Thread1: L1 L2
> Thread2: L2 T1
> 
> Not a deadlock because the trylock will just fail.  However, suppose we have:
> 
> Thread1: L1 L2
> Thread2: L2 T1
> 
> And then later:
> 
> Thread 3: L1 L2
> 
> When helgrind handles L2, it would already find the graph edge L1 -> L2 so wouldn't it just return 
> since that is the "correct order"?  David sent me some past e-mail and I saw some comments about 
> putting lock vs trylock into the graph.  Seems to me that when processing T2, helgrind would not 
> report a problem, but would add the T2 -> L1 link, and would also need to ensure that if L1 -> L2 
> happens in the future, it is reported.

Did not see much of the attached mails or discussions,
so I guess the reference to the discussions on valusers is:
http://thread.gmane.org/gmane.comp.debugging.valgrind/12616

Philippe

Re: [Valgrind-users] FW: Helgrind to-do list

[David F. <fa...@kd...>]

On Friday 27 September 2013 15:01:54 Phil Longstaff wrote:
> I was thinking about this one last night, and it's trickier than I first
> thought.
> 
> L = lock, T = trylock
> Thread1: L1 L2
> Thread2: L2 T1
> 
> Not a deadlock because the trylock will just fail.  However, suppose we
> have:
> 
> Thread1: L1 L2
> Thread2: L2 T1
> 
> And then later:
> 
> Thread 3: L1 L2
> 
> When helgrind handles L2, it would already find the graph edge L1 -> L2 so
> wouldn't it just return since that is the "correct order"?  David sent me
> some past e-mail and I saw some comments about putting lock vs trylock into
> the graph.  Seems to me that when processing T2, helgrind would not report
> a problem, but would add the T2 -> L1 link, and would also need to ensure
> that if L1 -> L2 happens in the future, it is reported.

A failing trylock cannot create a dead lock.
Only a succesful one, can.

So the question is whether we can assume a failed trylock could have succeeded 
in creating a deadlock if it hadn't failed.
In your particular example, we can.
In many other cases, we can't know that "what happened after the failed 
trylock" would have happened too, if it had succeded. There could be an if() 
statement :-)

So IMHO it's much easier to just drop failed trylocks and only remember 
successful ones, but yes, one can refine that for the case above, i.e. when 
the failed-trylock is the last thing in the chain.

If anything happens *after* a failed trylock, then one can't store a
"T1 -> anything" link.

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

Re: [Valgrind-users] FW: Helgrind to-do list

[Phil L. <plo...@sa...>]

I was thinking about this one last night, and it's trickier than I first thought.

L = lock, T = trylock
Thread1: L1 L2
Thread2: L2 T1

Not a deadlock because the trylock will just fail.  However, suppose we have:

Thread1: L1 L2
Thread2: L2 T1

And then later:

Thread 3: L1 L2

When helgrind handles L2, it would already find the graph edge L1 -> L2 so wouldn't it just return since that is the "correct order"?  David sent me some past e-mail and I saw some comments about putting lock vs trylock into the graph.  Seems to me that when processing T2, helgrind would not report a problem, but would add the T2 -> L1 link, and would also need to ensure that if L1 -> L2 happens in the future, it is reported.

-----Original Message-----
From: David Faure [mailto:fa...@kd...] 
Sent: Friday, September 27, 2013 9:38 AM
To: val...@li...
Cc: Phil Longstaff
Subject: Re: [Valgrind-users] FW: Helgrind to-do list

On Wednesday 25 September 2013 18:24:59 Phil Longstaff wrote:
> *         Don't update the lock-order graph, and don't check for errors,
> when a "try"-style lock operation happens (e.g. pthread_mutex_trylock).
> Such calls do not add any real restrictions to the locking order, 
> since they can always fail to acquire the lock, resulting in the 
> caller going off and doing Plan B (presumably it will have a Plan B). 
> Doing such checks could generate false lock-order errors and confuse users.

Assuming this one is what you numbered #4 (i.e. that you started to count at 1 and not 0) :-), then it's something I had started a long time ago, details are in the archive for this mailing-list (Nov 2012) (actually let me attached the mails here for convenience), and the testcase is at
https://bugs.kde.org/show_bug.cgi?id=243232

I would be very very glad if you could take over, I lack time and valgrind knowledge.

I'm also attaching my very preliminary & very old patch for it. IIRC it needs to be updated to actually implement what was discussed in the attached emails, in addition to making it work in  the first place...

--
David Faure, fa...@kd..., http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5

Re: [Valgrind-users] FW: Helgrind to-do list

[David F. <fa...@kd...>]

On Wednesday 25 September 2013 18:24:59 Phil Longstaff wrote:
> *         Don't update the lock-order graph, and don't check for errors,
> when a "try"-style lock operation happens (e.g. pthread_mutex_trylock).
> Such calls do not add any real restrictions to the locking order, since
> they can always fail to acquire the lock, resulting in the caller going off
> and doing Plan B (presumably it will have a Plan B). Doing such checks
> could generate false lock-order errors and confuse users.

Assuming this one is what you numbered #4 (i.e. that you started to count at 1 
and not 0) :-), then it's something I had started a long time ago, details are 
in the archive for this mailing-list (Nov 2012) (actually let me attached the 
mails here for convenience), and the testcase is at 
https://bugs.kde.org/show_bug.cgi?id=243232

I would be very very glad if you could take over, I lack time and valgrind 
knowledge.

I'm also attaching my very preliminary & very old patch for it. IIRC it needs 
to be updated to actually implement what was discussed in the attached emails,
in addition to making it work in  the first place...

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5