valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] threads vs main and invalid stack writes

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

>     alloca(4096);
>     __yell();

> 
> (gdb) monitor get_vbits 0xffeffeed0 256
> ________ ________ ________ ________ ________ ________ ________ ________
> ________ ________ ________ ________ ________ ________ ________ ________
> ________ ________ ________ ________ ________ ________ ________ ________
> ________ ________ ________ ________ ________ ________ ________ ________
> ________ ________ ________ ________ ffffffff ffffffff ffffffff ffffffff
> ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
> ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
> ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
> Address 0xFFEFFEED0 len 256 has 144 bytes unaddressable
> 
> Any ideas? It seems to depend on:
> 
>  - Some (small) number of threads being spawned.
>  - A > page-sized alloca().
>  - Reasonably sized memset on top.
>  - It's always the main thread which suffers.

Thank you for the small, reproducible testcase!

It's a bug in valgrind, so please file a bug report, and include the testcase.
See the "Bug Reports" entry in the left column of the main page
http://www.valgrind.org/ .

Meanwhile the trivial workaround is to memset every result of alloca.
Oh, and "#include <string.h>"

[Valgrind-users] threads vs main and invalid stack writes

[Daniel S. <da...@co...>]

Hi.

Hope s/o around here can help. 

I'm looking at some strange valgrind complaints when combining main(),
calling alloca() while spawning a couple pthreads.

I seem to have reduced it to the following program:

#include <pthread.h>
#include <alloca.h>
#include <assert.h>
#include <stdarg.h>

void *
nop(void *nil)
{
    return NULL;
}

void
__yell(void)
{
    char buf[256];
    memset(buf, 0, sizeof(buf)); /* <= */
}

int main(int argc, char **argv)
{
    pthread_t thr[4];
    int i, err;

    for (i = 0; i < sizeof(thr) / sizeof(*thr); i++) {
        err = pthread_create(&thr[i], NULL, nop, NULL);
        assert(!err);
    }

    alloca(4096);
    __yell();

    for (i = 0; i < sizeof(thr) / sizeof(*thr); i++)
        pthread_join(thr[i], NULL);

    return 0;
}

With that, valgrind typically fails as follows:

$ gcc -O0 -g test2.c -lpthread && /var/tmp/valgrind/bin/valgrind --vgdb-error=1 ./a.out
==23755== Memcheck, a memory error detector
==23755== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==23755== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info
==23755== Command: ./a.out
==23755== 
==23755== 
==23755== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==23755==   /path/to/gdb ./a.out
==23755== and then give GDB the following command
==23755==   target remote | /var/tmp/valgrind/lib/valgrind/../../bin/vgdb --pid=23755
==23755== --pid is optional if only one valgrind process is running
==23755== 
==23755== Invalid write of size 8
==23755==    at 0x4006B7: __yell (test2.c:16)
==23755==    by 0x40076C: main (test2.c:30)
==23755==  Address 0xffeffeed0 is on thread 1's stack
==23755== 
==23755== (action on error) vgdb me ... 

(gdb) print &buf
$6 = (char (*)[256]) 0xffeffeed0

(gdb) monitor get_vbits 0xffeffeed0 256
________ ________ ________ ________ ________ ________ ________ ________
________ ________ ________ ________ ________ ________ ________ ________
________ ________ ________ ________ ________ ________ ________ ________
________ ________ ________ ________ ________ ________ ________ ________
________ ________ ________ ________ ffffffff ffffffff ffffffff ffffffff
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
Address 0xFFEFFEED0 len 256 has 144 bytes unaddressable

Any ideas? It seems to depend on:

 - Some (small) number of threads being spawned.
 - A > page-sized alloca().
 - Reasonably sized memset on top.
 - It's always the main thread which suffers.

The real stuff I'm working with typically fails deeply in the dynamic linker,
preferably eglibc's dl-load.c:open_path building alloca'd path name to 
find nss code.

I'd add suppressions, but we've seen quite a bit of variance in the
number of code paths affected. 

The valgrind I'm testing with is 3.8.1. Ran into the original dl-load issue with 
3.7-Debian, iirc.

I tried svn trunk but that didn't seem to solve it.

Thanks + Cheers,
Daniel

Re: [Valgrind-users] Adding suppressions generates significantly more errors

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

On Tue, 2013-07-02 at 10:01 -0700, Kevin Lee wrote:
> I had a relatively simple suppression file that generated ~500 errors.  I
> wrote a script to select certain errors for suppression and generate an
> additional suppression file.  When I run with this additional suppression
> file, my errors explode to over 3000 errors.  I was expecting my errors to
> decrease from the previous 500 level.  Any ideas on why maybe happening?
No, but a guess might benefit from more  information such as
which tool with which options, what errors are being suppressed, and
 what are the new errors that are appearing when adding 
suppression entries, ...

And of course, a (if possible small) compilable test case will for
sure help the most.

> 
> Also, the execution time expanded by 42%.  This could be due to the
> significantly larger suppression list.
Also, would be nice to know the version of Valgrind you are using.

Note that in 3.8.1, the suppression matching mechanism was optimised.
In 3.9.0 (not yet released), the leak suppression entries can be
made more precise (e.g. to only match definite leaks).

Philippe

Re: [Valgrind-users] Adding suppressions generates significantly more errors

[Paul F. <pa...@fr...>]

On 2 Jul 2013, at 19:01, Kevin Lee wrote:

> I had a relatively simple suppression file that generated ~500 errors.  I
> wrote a script to select certain errors for suppression and generate an
> additional suppression file.  When I run with this additional suppression
> file, my errors explode to over 3000 errors.  I was expecting my errors to
> decrease from the previous 500 level.  Any ideas on why maybe happening?
> 
> Also, the execution time expanded by 42%.  This could be due to the
> significantly larger suppression list.


Hi

I assume that this is with memcheck?

Can you tell if the new errors are leak/reachable related?

A+
Paul

[Valgrind-users] Adding suppressions generates significantly more errors

[Kevin L. <kd...@qt...>]

I had a relatively simple suppression file that generated ~500 errors.  I
wrote a script to select certain errors for suppression and generate an
additional suppression file.  When I run with this additional suppression
file, my errors explode to over 3000 errors.  I was expecting my errors to
decrease from the previous 500 level.  Any ideas on why maybe happening?

Also, the execution time expanded by 42%.  This could be due to the
significantly larger suppression list.

Kevin



--
View this message in context: http://valgrind.10908.n7.nabble.com/Adding-suppressions-generates-significantly-more-errors-tp45799.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.

[Valgrind-users] Crash when running valgrind

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

When I run helgrind on an image which hasn't been stripped, I'm getting the following crash:

==12878== Helgrind, a thread error detector
==12878== Copyright (C) 2007-2012, and GNU GPL'd, by OpenWorks LLP et al.
==12878== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info

--12878-- Valgrind library directory: /usr/local/lib/valgrind
--12878-- Reading syms from /libexec/ld-elf.so.1
--12878--    object doesn't have a symbol table
--12878-- Reading syms from /d2/local/sandvine/ptsd/ptsd
--12878-- warning: DiCfSI 0x0 .. 0x0 outside mapped rw segments (NONE)
--12878-- warning: DiCfSI 0x1 .. 0x3 outside mapped rw segments (NONE)
--12878-- warning: DiCfSI 0x4 .. 0xa outside mapped rw segments (NONE)
--12878-- warning: DiCfSI 0xb .. 0x76 outside mapped rw segments (NONE)
--12878-- warning: DiCfSI 0x0 .. 0x0 outside mapped rw segments (NONE)
--12878-- warning: DiCfSI 0x1 .. 0x3 outside mapped rw segments (NONE)
--12878-- warning: DiCfSI 0x4 .. 0x47 outside mapped rw segments (NONE)
--12878-- warning: DiCfSI 0x0 .. 0x0 outside mapped rw segments (NONE)
--12878-- warning: DiCfSI 0x1 .. 0x3 outside mapped rw segments (NONE)
--12878-- warning: DiCfSI 0x4 .. 0x47 outside mapped rw segments (NONE)
--12878-- Reading syms from /d2/local/lib/valgrind/helgrind-amd64-freebsd
--12878--    object doesn't have a symbol table
--12878--    object doesn't have a dynamic symbol table
--12878-- Scheduler: using generic scheduler lock implementation.

valgrind: m_main.c:2180 (valgrind_main): Assertion 'seg' failed.
==12878==    at 0x3801E1E7: ??? (in /d2/local/lib/valgrind/helgrind-amd64-freebsd)

sched status:
  running_tid=1

Thread 1: status = VgTs_Init
==12878==    at 0x0: ???


   //--------------------------------------------------------------
   // Tell the tool about the initial client memory permissions
   //   p: aspacem
   //   p: mallocfree
   //   p: setup_client_stack
   //   p: setup_client_dataseg
   //
   // For each segment we tell the client about, look up in
   // addr2dihandle as created above, to see if there's a debuginfo
   // handle associated with the segment, that we can hand along
   // to the tool, to be helpful.
   //--------------------------------------------------------------
   VG_(debugLog)(1, "main", "Tell tool about initial permissions\n");
   { Addr*     seg_starts;
     Int       n_seg_starts;

     tl_assert(addr2dihandle);

     /* Mark the main thread as running while we tell the tool about
        the client memory so that the tool can associate that memory
        with the main thread. */
     tl_assert(VG_(running_tid) == VG_INVALID_THREADID);
     VG_(running_tid) = tid_main;

     seg_starts = VG_(get_segment_starts)( &n_seg_starts );
     vg_assert(seg_starts && n_seg_starts >= 0);

     /* show interesting ones to the tool */
     for (i = 0; i < n_seg_starts; i++) {
        Word j, n;
        NSegment const* seg
           = VG_(am_find_nsegment)( seg_starts[i] );
---->        vg_assert(seg);
        if (seg->kind == SkFileC || seg->kind == SkAnonC) {
          /* This next assertion is tricky.  If it is placed
             immediately before this 'if', it very occasionally fails.
             Why?  Because previous iterations of the loop may have
             caused tools (via the new_mem_startup calls) to do
             dynamic memory allocation, and that may affect the mapped
             segments; in particular it may cause segment merging to
             happen.  Hence we cannot assume that seg_starts[i], which
             reflects the state of the world before we started this
             loop, is the same as seg->start, as the latter reflects
             the state of the world (viz, mappings) at this particular
             iteration of the loop.

What is this complaining about?

Phil

Re: [Valgrind-users] why valgrind hit "__static_initialization_and_destruction_0(int, int)"

[<pa...@fr...>]

----- Original Message -----
> Hi All,
> 
> Can anyone tell me why valgrind hit
> “__static_initialization_and_destruction_0(int, int) ?

My guess is that you have one of the forms of static (file static, class static or function static).

> How to resolved I ?

Normally objects that were statically constructed get destroyed in reverse order upon program termination.

My guess is that you are allocating something in your constructor that is not deleted in the destructor.

A+
Paul

[Valgrind-users] why valgrind hit "__static_initialization_and_destruction_0(int, int)"

[Sanjay K. (sanjaku5) <san...@ci...>]

Hi All,
           Can anyone tell me why valgrind hit  "__static_initialization_and_destruction_0(int, int) ?
How to resolved I ?

Valgrind trace report of memory leak:

==26345== 22 bytes in 1 blocks are possibly lost in loss record 2,523 of 15,823
==26345==    at 0x401DE8F: operator new(unsigned int) (vg_replace_malloc.c:292)
==26345==    by 0x40BCE46: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) (new_allocator.h:88)
==26345==    by 0x40BEA68: std::string::_M_mutate(unsigned int, unsigned int, unsigned int) (basic_string.tcc:460)
==26345==    by 0x40BEBE9: std::string::_M_replace_safe(unsigned int, unsigned int, char const*, unsigned int) (basic_string.tcc:665)
==26345==    by 0x40BEC81: std::string::assign(char const*, unsigned int) (basic_string.tcc:268)
==26345==    by 0x40BEDFA: std::string::operator=(char const*) (char_traits.h:257)
==26345==    by 0x878D63E: diameter::diameter_initialize() (diameter.cpp:2445)
==26345==    by 0x87E78BC: diameter::diameter_entity::diameter_entity() (diameter_entity.cpp:10)
==26345==    by 0x8152727: __static_initialization_and_destruction_0(int, int) (flare_app.cpp:88)
==26345==    by 0x8152907: global constructors keyed to user_ent (flare_app.cpp:8495)
==26345==    by 0x89F7DEA: ??? (in /usr/local/flare/flare)
==26345==    by 0x804C3A0: ??? (in /usr/local/flare/flare)


Thanks,
Sanjay

[Valgrind-users] Fortran 95 support in valgrind?

[Sebastian F. <seb...@gm...>]

How good or bad does valgrind support fortran 95 applications? Are
there any catches or know bugs? is there a usage example for memcheck
and exp-sgcheck?

Sebastian

[Valgrind-users] helgrind: race with no other thread ?

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

Hello,

I have just had another case of a helgrind data race report with only one backtrace instead of two...
How can there be a race with only one contestant?

$ helgrind /d/kde/inst/kde4.10/bin/kactivitymanagerd --nocrashhandler --nofork
[snip debug output]
==11756== ----------------------------------------------------------------
==11756== 
==11756== Lock at 0x1191B6B0 was first observed
==11756==    at 0x4C2C548: QMutex_constructor_WRK (hg_intercepts.c:2246)
==11756==    by 0x4C309F8: QMutex::QMutex(QMutex::RecursionMode) (hg_intercepts.c:2252)
==11756==    by 0x7238F2A: QMutexPool::createMutex(int) (qmutexpool.cpp:138)
==11756==    by 0x7239051: QMutexPool::get(void const*) (qmutexpool_p.h:76)
==11756==    by 0x7390A14: signalSlotLock(QObject const*) (qobject.cpp:111)
==11756==    by 0x7397518: QMetaObjectPrivate::connect(QObject const*, int, QObject const*, int, QMetaObject const*, int, int*) (qobject.cpp:3162)
==11756==    by 0x7396085: QObject::connect(QObject const*, char const*, QObject const*, char const*, Qt::ConnectionType) (qobject.cpp:2650)
==11756==    by 0x4200D3: Resources::Resources(QObject*) (Resources.cpp:305)
==11756==    by 0x4160D4: Resources* runInQThread<Resources>() (Application.cpp:57)
==11756==    by 0x415D40: Application::Private::Private() (Application.cpp:88)
==11756==    by 0x4162E3: kamd::utils::d_ptr<Application::Private>::d_ptr() (d_ptr_implementation.h:29)
==11756==    by 0x4140F0: Application::Application() (Application.cpp:107)
==11756==    by 0x415019: Application::self() (Application.cpp:208)
==11756==    by 0x4152C2: main (Application.cpp:242)
==11756== 
==11756== Possible data race during read of size 8 at 0x11923F40 by thread #1
==11756== Locks held: 1, at address 0x1191B6B0
==11756==    at 0x7398617: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (qobject.cpp:3498)
==11756==    by 0x57B5924: KWindowSystem::activeWindowChanged(unsigned long) (kwindowsystem.moc:156)
==11756==    by 0x57B105C: KWindowSystemPrivate::x11Event(_XEvent*) (kwindowsystem_x11.cpp:197)
==11756==    by 0x566F049: KEventHackWidget::publicX11Event(_XEvent*) (ksystemeventfilter.cpp:43)
==11756==    by 0x566ECBB: KSystemEventFilterPrivate::filterEvent(void*) (ksystemeventfilter.cpp:102)
==11756==    by 0x566EC29: _k_eventFilter(void*) (ksystemeventfilter.cpp:91)
==11756==    by 0x73680F5: QAbstractEventDispatcher::filterEvent(void*) (qabstracteventdispatcher.cpp:542)
==11756==    by 0x7CC5EFE: QEventDispatcherX11::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (qeventdispatcher_x11.cpp:128)
==11756==    by 0x7376C97: QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (qeventloop.cpp:149)
==11756==    by 0x7376E2B: QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (qeventloop.cpp:204)
==11756==    by 0x7379FD5: QCoreApplication::exec() (qcoreapplication.cpp:1221)
==11756==    by 0x7BE4E97: QApplication::exec() (qapplication.cpp:3823)
==11756==    by 0x4152C7: main (Application.cpp:242)
==11756== 
==11756== Address 0x11923F40 is 16 bytes inside a block of size 104 alloc'd
==11756==    at 0x4C2BA9B: operator new(unsigned long) (vg_replace_malloc.c:319)
==11756==    by 0x7239F6B: QThreadPrivate::QThreadPrivate(QThreadData*) (qthread.cpp:190)
==11756==    by 0x723A148: QThread::QThread(QObject*) (qthread.cpp:408)
==11756==    by 0x416D66: Resources* runInQThread<Resources>()::Thread::Thread(Resources*) (Application.cpp:62)
==11756==    by 0x4160F4: Resources* runInQThread<Resources>() (Application.cpp:75)
==11756==    by 0x415D40: Application::Private::Private() (Application.cpp:88)
==11756==    by 0x4162E3: kamd::utils::d_ptr<Application::Private>::d_ptr() (d_ptr_implementation.h:29)
==11756==    by 0x4140F0: Application::Application() (Application.cpp:107)
==11756==    by 0x415019: Application::self() (Application.cpp:208)
==11756==    by 0x4152C2: main (Application.cpp:242)
==11756== 

valgrind-3.9.0.SVN, freshly updated.

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

Re: [Valgrind-users] mandatory function redirection error

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

>    $ ~/local/bin/valgrind -d -d -d -v -v -v --leak-check=yes ./clock_gettime CLOCK_MONOTONIC

> It looks like this might be the problem.  The only section I'm getting
> that starts with teh Load initial debug info looks like this:
> 
> --1688:1:main     Load initial debug info
> --1688-- Reading syms from /home/root/software/clock_gettime
> --1688--    svma 0x00000084ac, avma 0x00000084ac
> --1688-- Reading syms from /lib/ld-2.12.2.so
> --1688--    svma 0x0000000790, avma 0x0004000790
> --1688--   Considering /lib/ld-2.12.2.so ..
> --1688--   .. CRC mismatch (computed ebfc32b7 wanted 596e7f90)
> --1688--   Considering /lib/.debug/ld-2.12.2.so ..
> --1688--   .. CRC mismatch (computed 4cc18107 wanted 596e7f90)
> --1688--    object doesn't have a symbol table
> 
> The open() syscalls in the strace out I got from the approach you
> described in your other email didn't seem like they were mentioning a
> debug library either (I've attached that output).
> 
> The stuff in the debug output sounds like its saying the library is
> there but is corrupt (or possibly the wrong version or something)?


The correct debug info cannot be found.  The first attempted location was inside
the ld-2.12.2.so itself:
> --1688--   Considering /lib/ld-2.12.2.so ..
> --1688--   .. CRC mismatch (computed ebfc32b7 wanted 596e7f90)
but the debuginfo was not there.  (Perhaps it was empty, such as removed
by "strip" or "ld -S".)

The second attempted location was:
> --1688--   Considering /lib/.debug/ld-2.12.2.so ..
> --1688--   .. CRC mismatch (computed 4cc18107 wanted 596e7f90)
and that file does have debuginfo, but it does not match.

The third attempted location was (from the strace.out):
  1412  open("/usr/lib/debug/lib/ld-2.12.2.so", O_RDONLY) = -1 ENOENT (No such file or directory)
but that file was not found.

So /lib/ld-2.12.2.so does not match /lib/.debug/ld-2.12.2.so.
Either the wrong version was installed in the first place, or an update
was performed on one file but not the other.  Check the dates via "ls -l"
(and follow symlinks until you get to regular files.)
They should be close to each other: no more than about a minute apart.
Try a re-install of *both* files.

[Valgrind-users] Valgrind 3.8.1 wont produce libmpiwrap.a lib when I am using mpich-3.0.2

[Xiaocheng Z. <aro...@gm...>]

Hi, all
   I run into following problem when trying to use valgrind 3.8.1 to
inspect MPI problem


  configure:9294: mpicc -o conftest -g -O -fno-omit-frame-pointer -Wall
-fpic -m64  -fpic -shared -m64 conftest.c  >&5

  config.log                   |1941 /usr/bin/ld:
/home/xzou2/build/mpich-3.0.2/lib/libmpich.a(msgprint.o): relocation
R_X86_64_32 against `.text' can not be used when making a shared object;
recompile with -fPIC
  config.status*               |1942
/home/xzou2/build/mpich-3.0.2/lib/libmpich.a: could not read symbols: Bad
value

  config.sub*                  |1943 collect2: ld returned 1 exit status


I tried configure mpich with 'with-pic', but i have same kind of error.
i also tried to configure valgrind with '
--with-mpicc=any_bogus_name_will_do", the error is gone, but still, like
other cases, the valgrind does not generate libmpiwrap.a.

 any suggestions?  thanks

chris

[Valgrind-users] Valgrind 3.8.1 wont produce libmpiwrap.a lib when I am using mpich-3.0.2

[Xiaocheng Z. <aro...@gm...>]

Hi, all
   I run into this problem when trying to inspect MPI

[Valgrind-users] Does [Ctrl-C] will generate the proper memory leak ?

[Sanjay K. (sanjaku5) <san...@ci...>]

Hi All,
            There is following scenarios:

1.      Make the tunnel- sleep for 20 sec

2.      Break the tunnel - sleep for 200 sec

3.      Repeat 1 & 2.

4.      I do Ctrl-C  after 2nd step.
Does it give the proper memory leaks ?

Thanks,
Sanjay

Re: [Valgrind-users] Who's doing valgrind on Solaris?

[<pa...@fr...>]

----- Original Message -----
> Skip Montanaro <skip <at> pobox.com> writes:
> 
> > Who is doing the Solaris port?
> 
> There is some work-in-progress.
> Check http://bitbucket.org/setupji/valgrind-solaris


Hi

Here's the associated thesis

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&ved=0CE4QFjAD&url=https%3A%2F%2Fdip.felk.cvut.cz%2Fbrowse%2Fpdfcache%2Fpavlupe1_2012dipl.pdf&ei=EN3CUa-yF9Oy4AP-4YGwBw&usg=AFQjCNFrhP9odrMtVhtWhpi1ZnRfH5w7Xw&sig2=dOdgBgmpoEGyd_GE9XS8JA&bvm=bv.48175248,d.dmg 

A+
Paul

Re: [Valgrind-users] Who's doing valgrind on Solaris?

[ольга к. <olg...@gm...>]

Is it now possible to use valgrind for Solaris on a shell like ksh93 or bash?

Olga

On Thu, Jun 20, 2013 at 2:15 AM, Ivosh <iv...@iv...> wrote:
> Skip Montanaro <skip <at> pobox.com> writes:
>
>> Who is doing the Solaris port?
>
> There is some work-in-progress.
> Check http://bitbucket.org/setupji/valgrind-solaris
>
> --Ivosh
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users



-- 
      ,   _                                    _   ,
     { \/`o;====-    Olga Kryzhanovska   -====;o`\/ }
.----'-/`-/     olg...@gm...   \-`\-'----.
 `'-..-| /       http://twitter.com/fleyta     \ |-..-'`
      /\/\     Solaris/BSD//C/C++ programmer   /\/\
      `--`                                      `--`

Re: [Valgrind-users] Who's doing valgrind on Solaris?

[Ivosh <iv...@iv...>]

Skip Montanaro <skip <at> pobox.com> writes:

> Who is doing the Solaris port?

There is some work-in-progress.
Check http://bitbucket.org/setupji/valgrind-solaris

--Ivosh

[Valgrind-users] Getting Helgrind to disregard a lock

[Magnus R. <mag...@gm...>]

Hi,

in a unit testing harness, we have a lock that ensures that only one thread
runs at a time. In production, there is no such global lock, but instead our
code tries to protects its own data using various mutexes etc. We run our test
suite under Helgrind, but it seems like the global lock we have for testing
purposes causes false negatives as it prevents Helgrind from detecting data
races that could show up in production, since all threads in all testcases
always have at lest the global test harness lock held.

Is there a way to tell Helgrind to disregard that particular lock when
analyzing data races?

Best Regards
Magnus Reftel

Re: [Valgrind-users] Fwd: Basic Doubt

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

>> Is it [valgrind] only useful for standalone application?

> It's best with an application compiled with debug information.

 ... and dynamically linked (uses ld-linux.so and libc.so at run time.)

-- 

Re: [Valgrind-users] Fwd: Basic Doubt

[<pa...@fr...>]

----- Original Message -----
> Hi ,
> 
> Is it only useful for standalone application? Does it support any
> other OS than Linux?

Hi

It's best with an application compiled with debug information.

Other OSes - Mac OS X, Free BSD and Solaris that I've used with varying degrees of success.

A+
Paul

[Valgrind-users] Fwd: Basic Doubt

[Mani v. <man...@gm...>]

Hi ,

Is it only useful for standalone application?  Does it support any other OS
than Linux?

Re: [Valgrind-users] Basic Doubt

[<pa...@fr...>]

----- Original Message -----
> Hi ,
> 
> Apologies if it is silly question as i am a beginner.
> 
> Is it possible to use the memcheck tool for code rather than
> executable ( binary) ?

Hi

No, Valgrind is strictly runtime.

Google for static analysis tools.

A+
Paul

[Valgrind-users] Basic Doubt

[Mani v. <man...@gm...>]

Hi ,

Apologies if it is silly question as i am a beginner.

Is it possible to use the memcheck tool for code rather than executable (
binary) ?

As our system is complex and can't be tested/validated as single as binary.
Any other method is there so that i can intergrate/add valgrind plug-in to
our system.


-- 
Thanks & Regards,
Manivannan S
+91-9789122210

Re: [Valgrind-users] Why doesn't valgrind detect a memory leak for my application

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

Please don't top-post.

On 6/13/2013 12:26 AM, Sanjay Kumar (sanjaku5) wrote:
> Hi David,
>
> Below is final link command, printing at time linking, Please comments.
> Thanks,
> Sanjay
>
>
> <snip>
>
> /auto/mitg-sw/tools/bintools/rhel-x86_64/gcc/201203161400/bin/g++ -m32 -L /auto/mitg-sw/tools/bintools/rhel-x86_64/gcc/201203161400/lib --static -O0 -DFSM_STAT

The "--static" here is most likely the problem.  The g++ option for 
static linking is actually called "-static" (only one dash in front) but 
it looks like g++ is interpreting the two dashes as if they were one.

> -DHAS_AF_PACKET ./base_instance.o ./configfile.o ./config.o ./logging.o ./message_buffer.o ./timer.o ./ip_entity.o ./ip_container.o ./pcap_filter.o ./cfgdata.o ./ikev2_cfgdata.o ./cfgparams.o ./main.o ./flare_app.o ./load_app.o ./cli.o ./statistics.o ./sgsn.o ./sgsn_ipv4_addr.o ./user.o ./user_entity.o ./user_cfgparams.o ./gmm.o ./gmm_entity.o ./gmm_cfgparams.o ./nas_common.o ./aes.o ./mac_md5.o ./snow_3g.o ./uia2.o ./uea2.o ./snx_sha256.o ./NasSecurity.o ./esm.o ./esm_entity.o ./esm_cfgparams.o ./emm.o ./emm_entity.o ./emm_cfgparams.o ./smc.o ./smc_entity.o ./smc_cfgparams.o ./smr.o ./smr_entity.o ./smr_cfgparams.o ./smtl.o ./smtl_entity.o ./smtl_cfgparams.o ./sm.o ./sm_entity.o ./sm_cfgparams.o ./sndcp.o ./sndcp_entity.o ./sndcp_cfgparams.o ./gea1.o ./gea2.o ./gea3.o ./llc.o ./llc_entity.o ./llc_cfgparams.o ./bssgp.o ./bssgp_entity.o ./bssgp_cfgparams.o ./ns.o ./ns_entity.o ./ns_cfgparams.o ./nsvc_entity.o ./m3ua.o ./m3ua_entity.o ./m3ua_cfgparams.o ./m3ua_transport_entity.o ./ns_ip_entity.o ./gtpcv0.o ./gtpcv0_entity.o ./gtpcv0_cfgparams.o ./gtpcv1.o ./gtpcv1_entity.o ./gtpcv1_cfgparams.o ./gtpcv2.o ./gtpcv2_entity.o ./gtpcv2_cfgparams.o ./gtpu_entity.o ./gtpu.o ./gtpu_cfgparams.o ./ranap_entity.o ./ranap.o ./ranap_cfgparams.o ./S1apMsgs.o ./s1ap.o ./s1ap_entity.o ./s1ap_cfgparams.o ./sccp_entity.o ./sccp.o ./sccp_cfgparams.o ./mapss7.o ./mapss7_entity.o ./mapss7_cfgparams.o ./cap.o ./cap_entity.o ./cap_cfgparams.o ./tcap.o ./tcap_entity.o ./tcap_cfgparams.o ./diameter.o ./diameter_entity.o ./diameter_cfgparams.o ./radius.o ./radius_entity.o ./radius_cfgparams.o ./ikev2.o ./ikev2_entity.o ./ikev2_entity_responder.o ./ikev2_entity_informational.o ./ikev2_entity_child.o ./ikev2_cfgparams.o ./ikev2_payload.o ./ikev2_crypto.o ./aka.o ./ikev2_eap_common.o ./ikev2_eap_aka.o ./ikev2_eap_sim.o ./ipsec_data.o ./ipsec_data_cfgparams.o ./ipsec_data_entity.o ./ipse
> c_esp_entity.o ./sha1.o ./sha1-internal.o ./xfrm.o ./xfrm_entity.o ./xfrm_load_entity.o ./xfrm_cfgparams.o ./xfrm_message.o ./bssap.o ./bssap_entity.o ./bssap_cfgparams.o ./traffic.o ./tlv.o ./gx.o ./asn.o ./stargen.o ./eventbridge.o ./CliAttrib.o ./CliObject.o ./CliCommand.o ./CliObjectSyfer.o ./CliObjectSyferCard.o ./CliObjectEth.o  ./CliHandlerServer.o ./CliHandlerServerSyfer.o  ./libs/librohc.a ../../framework//cli/libs/glib-2.0.0/lib/libglib-2.0.a ./libs/libsnutils.a ./libs/libcommon.a ./libs/libasnbase.a ./libs/libs1apgen.a ./libs/libsctp.a ./libs/libpcap.a -L . -L ../syfer_ssl/openssl-0.9.8g/ -L../../framework//eventbridge -lssp -lsyfer_ssl -lcrypto -leventbridge -ldl -o flare
> ./libs/libpcap.a(nametoaddr.o): In function `pcap_nametoaddrinfo':
> nametoaddr.c:(.text+0xa3): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
> ./libs/libpcap.a(nametoaddr.o): In function `pcap_nametoaddr':
> nametoaddr.c:(.text+0x1a): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
> ./libs/libpcap.a(nametoaddr.o): In function `pcap_nametonetaddr':
> nametoaddr.c:(.text+0xdb): warning: Using 'getnetbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
> ./libs/libpcap.a(nametoaddr.o): In function `pcap_nametoproto':
> nametoaddr.c:(.text+0x2cb): warning: Using 'getprotobyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
> ./libs/libpcap.a(nametoaddr.o): In function `pcap_nametoport':
> nametoaddr.c:(.text+0x12f): warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

And of course these warnings indicate that your application is being 
linked statically, as Philippe suggested earlier.  Unless this is an 
embedded application, you generally won't want to link statically, and I 
wonder why it was done.

To run Valgrind, it will be simpler if you turn this off for debugging.  
If you aren't allowed to do make that kind of change to the Makefile 
structure even when debugging, you will need to follow the directions 
pointed out by Philippe (which I have never used; my applications are 
dynamically linked).

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

Re: [Valgrind-users] Why doesn't valgrind detect a memory leak for my application

[Sanjay K. (sanjaku5) <san...@ci...>]

Hi David,

Below is final link command, printing at time linking, Please comments.
Thanks,
Sanjay


/auto/mitg-sw/tools/bintools/rhel-x86_64/gcc/201203161400/bin/g++ -m32 -MM -Wextra -Werror -Wno-deprecated -fno-strict-aliasing -g -DMC2 -O0 -fstack-protecto
r-all -ffast-math -DDEBUG -DFSM_STAT -DHAS_AF_PACKET -DSYFER_IP_SPECIFIC -I ../syfer_ssl/openssl-0.9.8g/include/ -I ../syfer_ssl/ -I ../syfer_ssl/nitrox-driv
er/cavium/software/include/ -I ../../framework -I ../../framework//utils/protocols/s1apgen -I ../../framework//cli/libs/snutils/include -I ../../framework//u
tils/common -I ../../framework//utils/asnbase -I ../../framework//utils/snutils -I -I../../framework//utils/protocols/hnbapgen -I../../framework//utils/proto
cols/ranapgen -I../../framework//utils/protocols/s1apgen -I../../framework//utils/protocols/ruagen -I../../framework//utils/protocols/gmmgen -I../../framewor
k//utils/protocols/sabpgen -I../../framework//utils/protocols/gtpgen -I ../../framework/ -I ../../framework//common/includes -I ../../framework//cli/libs/snu
tils/include -I ../../framework//cli/libs/glib-2.0.0/include -I ../../framework//cli/libs/glib-2.0.0/include/glib -I ../../framework//cli/libs/libedit/include -I ../../framework//cli/libs/libash/include -I ../../framework//cli/libs/libevent-1.4.8-stable/include -I ../../framework//cli/libs/pccts/h -I../../framework//eventbridge ../cli/syfer/CliHandlerServerSyfer.cpp > CliHandlerServerSyfer.d

/auto/mitg-sw/tools/bintools/rhel-x86_64/gcc/201203161400/bin/g++ -m32 -L /auto/mitg-sw/tools/bintools/rhel-x86_64/gcc/201203161400/lib --static -O0 -DFSM_STAT -DHAS_AF_PACKET ./base_instance.o ./configfile.o ./config.o ./logging.o ./message_buffer.o ./timer.o ./ip_entity.o ./ip_container.o ./pcap_filter.o ./cfgdata.o ./ikev2_cfgdata.o ./cfgparams.o ./main.o ./flare_app.o ./load_app.o ./cli.o ./statistics.o ./sgsn.o ./sgsn_ipv4_addr.o ./user.o ./user_entity.o ./user_cfgparams.o ./gmm.o ./gmm_entity.o ./gmm_cfgparams.o ./nas_common.o ./aes.o ./mac_md5.o ./snow_3g.o ./uia2.o ./uea2.o ./snx_sha256.o ./NasSecurity.o ./esm.o ./esm_entity.o ./esm_cfgparams.o ./emm.o ./emm_entity.o ./emm_cfgparams.o ./smc.o ./smc_entity.o ./smc_cfgparams.o ./smr.o ./smr_entity.o ./smr_cfgparams.o ./smtl.o ./smtl_entity.o ./smtl_cfgparams.o ./sm.o ./sm_entity.o ./sm_cfgparams.o ./sndcp.o ./sndcp_entity.o ./sndcp_cfgparams.o ./gea1.o ./gea2.o ./gea3.o ./llc.o ./llc_entity.o ./llc_cfgparams.o ./bssgp.o ./bssgp_entity.o ./bssgp_cfgparams.o ./ns.o ./ns_entity.o ./ns_cfgparams.o ./nsvc_entity.o ./m3ua.o ./m3ua_entity.o ./m3ua_cfgparams.o ./m3ua_transport_entity.o ./ns_ip_entity.o ./gtpcv0.o ./gtpcv0_entity.o ./gtpcv0_cfgparams.o ./gtpcv1.o ./gtpcv1_entity.o ./gtpcv1_cfgparams.o ./gtpcv2.o ./gtpcv2_entity.o ./gtpcv2_cfgparams.o ./gtpu_entity.o ./gtpu.o ./gtpu_cfgparams.o ./ranap_entity.o ./ranap.o ./ranap_cfgparams.o ./S1apMsgs.o ./s1ap.o ./s1ap_entity.o ./s1ap_cfgparams.o ./sccp_entity.o ./sccp.o ./sccp_cfgparams.o ./mapss7.o ./mapss7_entity.o ./mapss7_cfgparams.o ./cap.o ./cap_entity.o ./cap_cfgparams.o ./tcap.o ./tcap_entity.o ./tcap_cfgparams.o ./diameter.o ./diameter_entity.o ./diameter_cfgparams.o ./radius.o ./radius_entity.o ./radius_cfgparams.o ./ikev2.o ./ikev2_entity.o ./ikev2_entity_responder.o ./ikev2_entity_informational.o ./ikev2_entity_child.o ./ikev2_cfgparams.o ./ikev2_payload.o ./ikev2_crypto.o ./aka.o ./ikev2_eap_common.o ./ikev2_eap_aka.o ./ikev2_eap_sim.o ./ipsec_data.o ./ipsec_data_cfgparams.o ./ipsec_data_entity.o ./ipsec_esp_entity.o ./sha1.o ./sha1-internal.o ./xfrm.o ./xfrm_entity.o ./xfrm_load_entity.o ./xfrm_cfgparams.o ./xfrm_message.o ./bssap.o ./bssap_entity.o ./bssap_cfgparams.o ./traffic.o ./tlv.o ./gx.o ./asn.o ./stargen.o ./eventbridge.o ./CliAttrib.o ./CliObject.o ./CliCommand.o ./CliObjectSyfer.o ./CliObjectSyferCard.o ./CliObjectEth.o  ./CliHandlerServer.o ./CliHandlerServerSyfer.o  ./libs/librohc.a ../../framework//cli/libs/glib-2.0.0/lib/libglib-2.0.a ./libs/libsnutils.a ./libs/libcommon.a ./libs/libasnbase.a ./libs/libs1apgen.a ./libs/libsctp.a ./libs/libpcap.a -L . -L ../syfer_ssl/openssl-0.9.8g/ -L../../framework//eventbridge -lssp -lsyfer_ssl -lcrypto -leventbridge -ldl -o flare
./libs/libpcap.a(nametoaddr.o): In function `pcap_nametoaddrinfo':
nametoaddr.c:(.text+0xa3): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
./libs/libpcap.a(nametoaddr.o): In function `pcap_nametoaddr':
nametoaddr.c:(.text+0x1a): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
./libs/libpcap.a(nametoaddr.o): In function `pcap_nametonetaddr':
nametoaddr.c:(.text+0xdb): warning: Using 'getnetbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
./libs/libpcap.a(nametoaddr.o): In function `pcap_nametoproto':
nametoaddr.c:(.text+0x2cb): warning: Using 'getprotobyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
./libs/libpcap.a(nametoaddr.o): In function `pcap_nametoport':
nametoaddr.c:(.text+0x12f): warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking





-----Original Message-----
From: David Chapman [mailto:dcc...@ac...] 
Sent: Thursday, June 13, 2013 11:57 AM
To: Sanjay Kumar (sanjaku5)
Cc: Philippe Waroquiers; val...@li...
Subject: Re: [Valgrind-users] Why doesn't valgrind detect a memory leak for my application

On 6/12/2013 10:29 PM, Sanjay Kumar (sanjaku5) wrote:
> Hi Philippe,
> Below is part of Make file where I have done the Linking:
>
> sslLIB=$(OUT_DIR)/libsyfer_ssl.a
>
> # pull in dependency info for *existing* .o files
> *********************************
> -include $(commonOBJS:.o=.d)
> -include $(sslOBJS:.o=.d)
> -include $(cliCOMMONOBJS:.o=.d)
> -include $(cliCLIOBJS:.o=.d)
> -include $(cliSYFERSERVEROBJS:.o=.d)
> -include $(cliSYFERCARDSERVEROBJS:.o=.d) -include 
> $(cliETHSERVERSERVEROBJS:.o=.d)
>
> all: $(OUT_DIR)/$(OUTNAME) $(OUT_DIR)/cli
>
> $(OUT_DIR)/cli : $(cliCOMMONOBJS) $(cliCLIOBJS)
>      @echo "LL $(LOPTS) $@" $(REDIRECT)
>      $(SILENT)$(LL) $(LOPTS) $(cliCOMMONOBJS) $(cliCLIOBJS)  -o cli 
> -lpthread
>
> $(OUT_DIR)/$(OUTNAME): $(VERSION_FILE) $(commonOBJS) $(sslLIB) $(cliCOMMONOBJS) $(cliSYFERSERVEROBJS)
>      @echo "LL $(LOPTS) $@" $(REDIRECT)
>      $(SILENT)$(LL) $(LOPTS) $(commonOBJS) $(cliCOMMONOBJS) 
> $(cliSYFERSERVEROBJS) ./libs/librohc.a $(LIB_GLIB_DIR)/libglib-2.0.a 
> ./libs/libsnutils.a ./libs/libcommon.a ./libs/libasnbase.a 
> ./libs/libs1apgen.a ./libs/libsctp.a ./libs/libpcap.a $(LIB_PATH) 
> -lssp -lsyfer_ssl -lcrypto -leventbridge -ldl -o $(OUTNAME)

Without knowing the exact link options, there is no way for anyone on this list to determine what is going wrong.  Please paste the link command as printed during the build process, perhaps with proprietary object file names stripped out.  We don't know what, for example, "$(LOPTS)" expands to, and even "$(LL)" could have some linker flags in it.  These are your Makefile's definitions; they are not universal.


>
> $(OUT_DIR)/syfercard : $(cliCOMMONOBJS) $(cliSYFERCARDSERVEROBJS)
>      @echo "LL $(LOPTS) $@" $(REDIRECT)
>      $(SILENT)$(LL) $(LOPTS) $(cliCOMMONOBJS) 
> $(cliSYFERCARDSERVEROBJS)  -o syfercard
>
> $(OUT_DIR)/ethserver : $(cliCOMMONOBJS) $(cliETHSERVERSERVEROBJS)
>      @echo "LL $(LOPTS) $@" $(REDIRECT)
>      $(SILENT)$(LL) $(LOPTS) $(cliCOMMONOBJS) 
> $(cliETHSERVERSERVEROBJS)  -o ethserver -lpthread
>
> *********************************
>
> Could you please comments on this.
> What modification I need to do here ?
>
> Thanks,
> Sanjay
>
> -----Original Message-----
> From: Philippe Waroquiers [mailto:phi...@sk...]
> Sent: Thursday, June 13, 2013 1:38 AM
> To: David Chapman
> Cc: Sanjay Kumar (sanjaku5); val...@li...
> Subject: Re: [Valgrind-users] Why doesn't valgrind detect a memory 
> leak for my application
>
> Sanjay,
>>> --11597--    object doesn't have a dynamic symbol table
> With the above
> and the below stacktrace, it looks like this application is statically linked (or at least, the malloc lib is statically linked).
> valgrind can find leaks if malloc lib is statically linked (you need to use --soname-synonyms=.... to indicate malloc is statically linked).
> However, a completely statically linked application causes other problems.
> You should have at least one (even dummy) dynamically linked lib to have the dynamic loader be invoked in your process otherwise valgrind cannot "LD_PRELOAD" some of its own .so.
>
> Philippe
>
>>> ==11597== Conditional jump or move depends on uninitialised value(s)
>>>
>>> ==11597==    at 0x8A838B5: __register_atfork
>>> (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8A68074: ptmalloc_init (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8A6C265: malloc_hook_ini
>>> (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8A6BDCE: malloc (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8AA893B: _dl_init_paths
>>> (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8A8BDBB: _dl_non_dynamic_init
>>> (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8A8CA75: __libc_init_first
>>> (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8A3E460: (below main) (in /usr/local/flare/flare)
>
>
>
>


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