valgrind-users — General discussion list for Valgrind users

[Valgrind-users] 答复: valgrind3.9.0 does not work with my application.

[Guoqiuping <guo...@hu...>]

uname -a:
Linux TB2SEE1 2.6.16.46-0.12-smp #1 SMP Thu May 17 14:00:09 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux

rpm -q glibc:
glibc-2.4.31.43.6.PTE.473402.0

/lib64/libc.so.6->libc.2.4.so

-----邮件原件-----
发件人: John Reiser [mailto:jr...@Bi...] 
发送时间: 2014年6月30日 11:19
收件人: val...@li...
主题: Re: [Valgrind-users] valgrind3.9.0 does not work with my application.

> My application work without using valgrind, but when I use valgrind 
> 390

Thank you for mentioning the version number of valgrind.

with my application, the application crash soon after start:
> 
>  
> 
> ==25545== Process terminating with default action of signal 11
> 
> (SIGSEGV): dumping core
> 
> ==25545==  Access not within mapped region at address 0x86C006000
> 
> ==25545==    at 0x52308C4: _IO_vfscanf (in /lib64/libc-2.4.so)

Please tell us what hardware architecture, and which operating system and version, and which distribution.  Post the output from "uname -a", which gives good information.

/lib64 implies a 64-bit machine.  Current glibc on x86_64 boxes is something like:
	$ ls -l /lib64/libc-*.so
	-rwxr-xr-x. 1 root root 2108632 Nov 16  2013 /lib64/libc-2.17.so [that's Fedora 19] so libc-2.4.so must be something else.

> The stack trace seems like the Bug 95667 reported in 2004. I think the bug has been already solved. But why it happened again for me?

Bug 95667 [in 2004, ten years ago] was on x86*,  Because the bug and the fix are machine-dependent, then perhaps a similar situation arose afterwards on a different machine architecture.  What architecture *are* you running?


------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] valgrind3.9.0 does not work with my application.

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

> My application work without using valgrind, but when I use valgrind 390 

Thank you for mentioning the version number of valgrind.

with my application, the application crash soon after start:
> 
>  
> 
> ==25545== Process terminating with default action of signal 11
> 
> (SIGSEGV): dumping core
> 
> ==25545==  Access not within mapped region at address 0x86C006000
> 
> ==25545==    at 0x52308C4: _IO_vfscanf (in /lib64/libc-2.4.so)

Please tell us what hardware architecture, and which operating system and version,
and which distribution.  Post the output from "uname -a", which gives good information.

/lib64 implies a 64-bit machine.  Current glibc on x86_64 boxes is something like:
	$ ls -l /lib64/libc-*.so
	-rwxr-xr-x. 1 root root 2108632 Nov 16  2013 /lib64/libc-2.17.so
[that's Fedora 19] so libc-2.4.so must be something else.

> The stack trace seems like the Bug 95667 reported in 2004. I think the bug has been already solved. But why it happened again for me?

Bug 95667 [in 2004, ten years ago] was on x86*,  Because the bug and the fix
are machine-dependent, then perhaps a similar situation arose afterwards
on a different machine architecture.  What architecture *are* you running?

[Valgrind-users] valgrind3.9.0 does not work with my application.

[Guoqiuping <guo...@hu...>]

Hello:
My application work without using valgrind, but when I use valgrind 390 with my application, the application crash soon after start:


==25545== Process terminating with default action of signal 11

(SIGSEGV): dumping core

==25545==  Access not within mapped region at address 0x86C006000

==25545==    at 0x52308C4: _IO_vfscanf (in /lib64/libc-2.4.so)

==25545==    by 0x523E7A4: vsscanf (in /lib64/libc-2.4.so)

==25545==    by 0x52399E7: sscanf (in /lib64/libc-2.4.so)

==25545==    by 0x47455D32:

ngin::common::V1_0_0_0::resourcemonitor::CSystemResCtrlThread::priRefreshTotalMEMInfo()(resourcedetect.cpp:647)

==25545==    by 0x47455F03:

ngin::common::V1_0_0_0::resourcemonitor::CSystemResCtrlThread::priCalcTotalMEMUsage()(resourcedetect.cpp:975)

==25545==    by 0x47458274:

ngin::common::V1_0_0_0::resourcemonitor::CSystemResCtrlThread::priRefreshSysResInfo()(resourcedetect.cpp:1271)

==25545==    by 0x474587C9:

ngin::common::V1_0_0_0::resourcemonitor::CSystemResCtrlThread::run()(resourcedetect.cpp:86)

==25545==    by 0x6A27554: startHook (Thread.cpp:411)

==25545==    by 0x4A23142: start_thread (in /lib64/libpthread-2.4.so)

==25545==    by 0x529E74C: clone (in /lib64/libc-2.4.so)

==25545==  If you believe this happened as a result of a stack ==25545==  overflow in your program's main thread (unlikely but ==25545==  possible), you can try to increase the size of the ==25545==  main thread stack using the --main-stacksize= flag.

==25545==  The main thread stack size used in this run was 16777216.
==25545==

The stack trace seems like the Bug 95667 reported in 2004. I think the bug has been already solved. But why it happened again for me?

My application's code as below:
resourcedetect.cpp:647
647:       if ( MEM_INFO_RECORDS_ITEM_NUM != sscanf(m_arrArray4TempBuff,
648:                                            "%s %llu",
649:                                            m_arrCurTotalMemInfo[i].name,
650:                                            &m_arrCurTotalMemInfo[i].value))

The type of m_arrCurTotalMemInfo[i].name is char[], And the type of m_arrCurTotalMemInfo[i].value is int8, so I think there is no bug in my application.

Anyone could help me?

Re: [Valgrind-users] helgrind and threadsafe-statics

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

On Monday 09 June 2014 08:39:45 Patrick J. LoPresti wrote:
> Interesting! So on x86 and similar, they implement thread-safe Meyers
> singletons via the double-checked locking anti-pattern... Which is
> actually safe thanks to Intel's not-exactly-relaxed memory model.

Interesting indeed.
 
> > If g++ would be modified such that the "if (!guard.first_byte)" test can
> > be skipped at run-time then it would become possible for Helgrind and
> > DRD to recognize static initialization
> 
> If I understand you correctly (?), you plan to ask the g++ maintainers
> to tamper with their fast path to make life easier for Helgrind (?)

Yeah, I can't really see that happening, either.
Unless some of you have a really good relationship with the gcc maintainers 
:-)
 
> If so, I would suggest having a Plan B...
> 
> Would it make sense to re-think the happens-before/happens-after
> annotation macros for C++11?

Not sure what you mean exactly, so at the risk of asking the same question:

would it be possible for me to annotate a global static with some special 
macros that make helgrind understand what's happening?

I know, annotating all global statics one by one sounds horrible, but actually 
in my case they're already encapsulated in a macro, and I just need a way to 
remove all these false positives in order for helgrind to be usable.

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

Re: [Valgrind-users] top and massif about jack2 memory usage

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

29.05.2014, 21:45, "Maurice van Swaaij" <ma...@bl...>:
> Valgrind doesn't track memory allocation through mmap, mremap and brk.
>
> You can use massif with the option  --pages-as-heap=yes to track those instead of malloc etc.

But this will overestimate used memory because malloc mmaps much more memory than it is really used.

Better solution would be to mark such (de)allocations with VALGRIND_MALLOCLIKE_BLOCK and
VALGRIND_FREELIKE_BLOCK in code [1]

[1] http://valgrind.org/docs/manual/manual-core-adv.html

-- 
Regards,
Konstantin

Re: [Valgrind-users] Need the latest development Valgrind sources

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

On 18/06/14 07:07, Ashoka K wrote:
> I tried using the SVN checkout as mentioned at valgrind.org and
> getting timeout on checkou.
>
>
> $ svn co svn://svn.valgrind.org/valgrind/trunk valgrind
> svn: Can't connect to host 'svn.valgrind.org': Connection timed out
>
> ping  to svn.valgrind.org works correctly.

You probably need to talk to whoever manages your firewall then as it 
appears than the svn port (3690) is blocked.

Tom

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

Re: [Valgrind-users] Need the latest development Valgrind sources

[Ashoka K <ash...@gm...>]

I tried using the SVN checkout as mentioned at valgrind.org and
getting timeout on checkou.


$ svn co svn://svn.valgrind.org/valgrind/trunk valgrind
svn: Can't connect to host 'svn.valgrind.org': Connection timed out

ping  to svn.valgrind.org works correctly.



On Wed, Jun 18, 2014 at 11:32 AM, Ashoka K <ash...@gm...> wrote:
> Hi,
>
> Can anybody point me to the latest development branch of Valgrind sources.
>
> AK

[Valgrind-users] Need the latest development Valgrind sources

[Ashoka K <ash...@gm...>]

Hi,

Can anybody point me to the latest development branch of Valgrind sources.

AK

Re: [Valgrind-users] Stack trace missing frame with inlined allocation function?

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

On Sat, 2014-04-12 at 19:16 -0400, Paul Smith wrote:
> > I would be happy if valgrind could do the magic on its own.
Recent SVN version are doing the magic

> 
> Boy, me too! :-).
> 
> I don't have the time to learn enough about Valgrind to attempt a fix
> myself but I'm willing to test any patches, etc. anyone wants to send
> along.  And I have enough programming fu to be able to, if not run, then
> at least amble with a proposed patch on my own.
Test and feedback welcome (you need to get and build an SVN version).

Thanks

Philippe

Re: [Valgrind-users] helgrind and threadsafe-statics

[Patrick J. L. <lop...@gm...>]

On Mon, Jun 9, 2014 at 12:53 AM, Bart Van Assche <bva...@ac...> wrote:
>
> I think g++ will have to be modified to allow Helgrind and DRD to
> recognize thread-safe statics on architectures that do not have relaxed
> memory consistency. From the gcc source file gcc/cp/decl.c I derived
> that on architectures without relaxed memory consistency that g++
> protects static initialization as follows:
>
>            static <type> guard;
>            if (!guard.first_byte) {
>              if (__cxa_guard_acquire (&guard)) {
>                bool flag = false;
>                try {
>                  // Do initialization.
>                  flag = true; __cxa_guard_release (&guard);
>                  // Register variable for destruction at end of program.
>                } catch {
>                  if (!flag) __cxa_guard_abort (&guard);
>                }
>            }

Interesting! So on x86 and similar, they implement thread-safe Meyers
singletons via the double-checked locking anti-pattern... Which is
actually safe thanks to Intel's not-exactly-relaxed memory model.

> If g++ would be modified such that the "if (!guard.first_byte)" test can
> be skipped at run-time then it would become possible for Helgrind and
> DRD to recognize static initialization

If I understand you correctly (?), you plan to ask the g++ maintainers
to tamper with their fast path to make life easier for Helgrind (?)

If so, I would suggest having a Plan B...

Would it make sense to re-think the happens-before/happens-after
annotation macros for C++11?

Or -- just thinking out loud here -- devise a way to encode this sort
of information in the debug section, and convince the GCC+Clang folks
to implement it (e.g. "-gannotate-memory-model" or somesuch)?

Here is my concern. C++11 provides a fairly elaborate threading and
memory model, with lots of built-in synchronization primitives, memory
barriers, various flavors of ordered loads and stores, etc. As more
and more of these get direct (open-coded) compiler support, and get
used for interesting lock-free algorithms and such, it is going to get
increasingly difficult for Helgrind to figure out what is going on.
Fixing this in general, if possible, would be better than playing
whack-a-mole.

Or am I way off base?

 - Pat

Re: [Valgrind-users] helgrind and threadsafe-statics

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

On 06/09/14 13:16, Olivier Goffart wrote:
> On Monday 09 June 2014 09:53:37 Bart Van Assche wrote:
>> If g++ would be modified such that the "if (!guard.first_byte)" test can
>> be skipped at run-time then it would become possible for Helgrind and
>> DRD to recognize static initialization by intercepting the
>> __cxa_guard_*() functions. However, I'm not sure which mechanism the gcc
>> maintainers will prefer for disabling that if-test at run-time.
> 
> Just an idea: Is it not possible to record guard's address on 
> __cxa_guard_release, and then consider that an access to guard as an happens 
> after?
> I don't know the internals of helgrind, so I can't say if it is possible, or 
> if it would be too slow.
> Or is __cxa_guard_* used for more than the static initialization?

This is certainly possible but I don't see how to implement this without
slowing down Helgrind and DRD significantly.

Bart.

Re: [Valgrind-users] cannot get Helgrind/DRD work with C++11 thread

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

On 06/09/14 08:51, Dave Ohlsson wrote:
> int i = 0;
> 
> int main()
> {
>     std::thread t1( []() { i = 1; } );
>     std::thread t2( []() { i = 2; } );
>     t1.join();
>     t2.join();
>     std::cerr << "i = " << i << std::endl;
>     return 0;
> }
> 
> [other code as before]
> </updated part of main.cc>
> 
> The problem now is that DRD does not warn about the data race.

Can you repeat this test with a sleep(1) inserted before "i = 1" ? This
false negative is maybe caused by std::thread using a shared pointer to
manage the created thread. Maybe that annotation informs DRD that i = 1
has finished before i = 2 is executed, hence the false negative.

Bart.

Re: [Valgrind-users] helgrind and threadsafe-statics

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

On 06/08/14 19:09, David Faure wrote:
> I'm using helgrind quite a lot these days, and I love it.
> 
> However I wonder if it doesn't give me false positives for the case of reading 
> a value from a static object, which was set in the constructor.
> 
> Given that gcc does indeed implement "threadsafe statics" as per C++11 (but 
> even before C++11 came out), one can assume that gcc does "something like" a 
> mutex around the creation of the object, and therefore that there is a 
> "happens before" relation between the end of the constructor and the use of 
> this object later on, right?
> 
> In that case it would seem that helgrind needs to learn that, to avoid many 
> false positives.
> 
> Testcase attached.
> 
> The assembly code says
>         call    __cxa_guard_acquire
>         testl   %eax, %eax
>         je      .L3
>         .loc 1 16 0 discriminator 2
>         movl    $_ZZ11threadStartPvE9singleton, %edi
>         call    _ZN9SingletonC1Ev
>         movl    $_ZGVZ11threadStartPvE9singleton, %edi
>         call    __cxa_guard_release
> .L3:
> 
> IIRC __cxa_guard_acquire/release is the protection around the static, but I'm 
> not sure exactly what this means. Is there an actual happens-before relation 
> here?

I think g++ will have to be modified to allow Helgrind and DRD to
recognize thread-safe statics on architectures that do not have relaxed
memory consistency. From the gcc source file gcc/cp/decl.c I derived
that on architectures without relaxed memory consistency that g++
protects static initialization as follows:

           static <type> guard;
           if (!guard.first_byte) {
             if (__cxa_guard_acquire (&guard)) {
               bool flag = false;
               try {
                 // Do initialization.
                 flag = true; __cxa_guard_release (&guard);
                 // Register variable for destruction at end of program.
               } catch {
                 if (!flag) __cxa_guard_abort (&guard);
               }
           }

If g++ would be modified such that the "if (!guard.first_byte)" test can
be skipped at run-time then it would become possible for Helgrind and
DRD to recognize static initialization by intercepting the
__cxa_guard_*() functions. However, I'm not sure which mechanism the gcc
maintainers will prefer for disabling that if-test at run-time.

Bart.

Re: [Valgrind-users] cannot get Helgrind/DRD work with C++11 thread

[Dave O. <dav...@gm...>]

[THERE ARE STILL PROBLEMS - SEE NEAR THE END OF THIS MESSAGE]

Hi,

Thank you for the updated instructions.

I tried again, like this:

<main.cc>
#include <valgrind/drd.h>
#define _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(addr)
ANNOTATE_HAPPENS_BEFORE(addr)
#define _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(addr)
 ANNOTATE_HAPPENS_AFTER(addr)

#include <iostream>
#include <thread>

int main()
{
    std::thread t( []() { } );
    t.join();
    std::cerr << "Done." << std::endl;
    return 0;
}

//
// From libstdc++-v3/src/c++11/thread.cc
//

extern "C" void* execute_native_thread_routine(void* __p)
{
  std::thread::_Impl_base* __t = static_cast<std::thread::_Impl_base*>(__p);
  std::thread::__shared_base_type __local;
  __local.swap(__t->_M_this_ptr);

  __try {
    __t->_M_run();
  } __catch(const __cxxabiv1::__forced_unwind&) {
    __throw_exception_again;
  } __catch(...) {
    std::terminate();
  }

  return 0;
}

#include <system_error>

namespace std
{
  void thread::_M_start_thread(__shared_base_type __b)
  {
    if (!__gthread_active_p())
#if __EXCEPTIONS
      throw system_error(make_error_code(errc::operation_not_permitted),
                         "Enable multithreading to use std::thread");
#else
      __throw_system_error(int(errc::operation_not_permitted));
#endif

    __b->_M_this_ptr = __b;
    int __e = __gthread_create(&_M_id._M_thread,
execute_native_thread_routine,
                               __b.get());
    if (__e) {
      __b->_M_this_ptr.reset();
      __throw_system_error(__e);
    }
  }
}
</main.cc>

The false positives are now gone:

$ g++ -std=c++11 -Wall -Wextra -pthread main.cc
$ ./a.out
Done.
$ valgrind --tool=drd ./a.out
==13462== drd, a thread error detector
==13462== Copyright (C) 2006-2011, and GNU GPL'd, by Bart Van Assche.
==13462== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==13462== Command: ./a.out
==13462==
Done.
==13462==
==13462== For counts of detected and suppressed errors, rerun with: -v
==13462== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 from 12)

So far, so good.

If, however, I replace main() by the following bogus code:

<updated part of main.cc>
[other code as before]

int i = 0;

int main()
{
    std::thread t1( []() { i = 1; } );
    std::thread t2( []() { i = 2; } );
    t1.join();
    t2.join();
    std::cerr << "i = " << i << std::endl;
    return 0;
}

[other code as before]
</updated part of main.cc>

The problem now is that DRD does not warn about the data race:

$ g++ -std=c++11 -Wall -Wextra -pthread main.cc
$ ./a.out
i = 2
$ valgrind --tool=drd ./a.out
==14480== drd, a thread error detector
==14480== Copyright (C) 2006-2011, and GNU GPL'd, by Bart Van Assche.
==14480== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==14480== Command: ./a.out
==14480==
i = 2
==14480==
==14480== For counts of detected and suppressed errors, rerun with: -v
==14480== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 from 12)

My setup has not changed:
- RedHad Linux 2.6
- g++ 4.7.2
- Valgrind 3.7.0

-- dave


On Sat, Jun 7, 2014 at 4:50 PM, Bart Van Assche <bva...@ac...> wrote:

> On 06/06/14 09:33, Dave Ohlsson wrote:
> > However, the code you posted, and the included comments, match pretty
> > much what I already did.
>
> Hello Dave,
>
> I have updated the C++11 instructions in the DRD manual and also the
> drd/tests/std_thread.cpp test program. The DRD manual can be generated
> as follows:
>
> $ make -sC docs html-docs
> $ xdg-open docs/html/drd-manual.html
>
> Can you have a look ?
>
> Thanks,
>
> Bart.
>

[Valgrind-users] helgrind and threadsafe-statics

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

Hello,

I'm using helgrind quite a lot these days, and I love it.

However I wonder if it doesn't give me false positives for the case of reading 
a value from a static object, which was set in the constructor.

Given that gcc does indeed implement "threadsafe statics" as per C++11 (but 
even before C++11 came out), one can assume that gcc does "something like" a 
mutex around the creation of the object, and therefore that there is a 
"happens before" relation between the end of the constructor and the use of 
this object later on, right?

In that case it would seem that helgrind needs to learn that, to avoid many 
false positives.

Testcase attached.

The assembly code says
        call    __cxa_guard_acquire
        testl   %eax, %eax
        je      .L3
        .loc 1 16 0 discriminator 2
        movl    $_ZZ11threadStartPvE9singleton, %edi
        call    _ZN9SingletonC1Ev
        movl    $_ZGVZ11threadStartPvE9singleton, %edi
        call    __cxa_guard_release
.L3:

IIRC __cxa_guard_acquire/release is the protection around the static, but I'm 
not sure exactly what this means. Is there an actual happens-before relation 
here?

helgrind log:

==31469== Possible data race during read of size 4 at 0x602068 by thread #3
==31469== Locks held: none
==31469==    at 0x400ADF: threadStart(void*) (testcase_local_static.cpp:17)
==31469==    by 0x4C2D151: mythread_wrapper (hg_intercepts.c:233)
==31469==    by 0x4E3C0DA: start_thread (pthread_create.c:309)
==31469==    by 0x595B90C: clone (clone.S:111)
==31469== 
==31469== This conflicts with a previous write of size 4 by thread #2
==31469== Locks held: none
==31469==    at 0x400BC6: Singleton::Singleton() (testcase_local_static.cpp:9)
==31469==    by 0x400AD4: threadStart(void*) (testcase_local_static.cpp:16)
==31469==    by 0x4C2D151: mythread_wrapper (hg_intercepts.c:233)
==31469==    by 0x4E3C0DA: start_thread (pthread_create.c:309)
==31469==    by 0x595B90C: clone (clone.S:111)


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

Re: [Valgrind-users] cannot get Helgrind/DRD work with C++11 thread

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

On 06/06/14 09:33, Dave Ohlsson wrote:
> However, the code you posted, and the included comments, match pretty
> much what I already did.

Hello Dave,

I have updated the C++11 instructions in the DRD manual and also the
drd/tests/std_thread.cpp test program. The DRD manual can be generated
as follows:

$ make -sC docs html-docs
$ xdg-open docs/html/drd-manual.html

Can you have a look ?

Thanks,

Bart.

Re: [Valgrind-users] cannot get Helgrind/DRD work with C++11 thread

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

On 06/06/14 09:33, Dave Ohlsson wrote:
> However, the code you posted, and the included comments, match pretty
> much what I already did.

I'm afraid that means that the instructions for shared pointer
annotation in the libstdc++ manual are still broken. See also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51504 for more information.

Bart.

Re: [Valgrind-users] cannot get Helgrind/DRD work with C++11 thread

[Dave O. <dav...@gm...>]

Hi Bart,

Thank you for trying to help.

However, the code you posted, and the included comments, match pretty much
what I already did.

So, to rehash:

1. I use:
- RedHad Linux 2.6
- g++ 4.7.2
- Valgrind 3.7.0

2. I copy-paste the code from your message to main.cc, the one difference
being drd.h's path:

#include <valgrind/drd.h>
#define _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(addr) \
  ANNOTATE_HAPPENS_BEFORE(addr)
#define _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(addr) \
  ANNOTATE_HAPPENS_AFTER(addr)
#define _GLIBCXX_EXTERN_TEMPLATE -1

#include <iostream>
#include <thread>

int main(int argc, char** argv)
{
  std::thread t( []() { } );
  t.join();
  std::cerr << "Done.\n";
  return 0;
}

3. I build the program:

    $ g++ -std=c++11 -Wall -Wextra -pthread main.cc
    main.cc:11:5: warning: unused parameter 'argc' [-Wunused-parameter]

    main.cc:11:5: warning: unused parameter 'argv' [-Wunused-parameter]


4. I run the program:

    $ ./a.out

    Done.


5. I run the program with DRD:

    $ valgrind --tool=drd ./a.out


=> I get a bunch of false positives - "Possible data race during write of
size 8", etc. - see my post at
http://stackoverflow.com/questions/24060626/cannot-get-helgrind-drd-work-with-c11-thread

What's the problem?

-- dave


On Fri, Jun 6, 2014 at 10:01 AM, Bart Van Assche <bva...@ac...> wrote:

> On 06/06/14 07:27, Dave Ohlsson wrote:
> > I posted yesterday a question to stackoverflow regarding problems I am
> > having with Helgrind/DRD and C++11 thread:
> >
> >
> http://stackoverflow.com/questions/24060626/cannot-get-helgrind-drd-work-with-c11-thread
> >
> > but got no answer.
>
> I think the source code comments in the test program below answer your
> question.
>
> Bart.
>
> $ cat drd/tests/std_thread.cpp
> // Test whether no race conditions are reported on std::thread. Note: since
> // the implementation of std::thread uses the shared pointer
> implementation,
> // that implementation has to be annotated in order to avoid false
> positives.
> // See also http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html for
> more
> // information.
>
> #include "../../drd/drd.h"
> #define _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(addr) \
>   ANNOTATE_HAPPENS_BEFORE(addr)
> #define _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(addr) \
>   ANNOTATE_HAPPENS_AFTER(addr)
> #define _GLIBCXX_EXTERN_TEMPLATE -1
>
> #include <iostream>
> #include <thread>
>
> int main(int argc, char** argv)
> {
>   std::thread t( []() { } );
>   t.join();
>   std::cerr << "Done.\n";
>   return 0;
> }
>
>

Re: [Valgrind-users] cannot get Helgrind/DRD work with C++11 thread

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

On 06/06/14 07:27, Dave Ohlsson wrote:
> I posted yesterday a question to stackoverflow regarding problems I am
> having with Helgrind/DRD and C++11 thread:
> 
> http://stackoverflow.com/questions/24060626/cannot-get-helgrind-drd-work-with-c11-thread
> 
> but got no answer.

I think the source code comments in the test program below answer your question.

Bart.

$ cat drd/tests/std_thread.cpp
// Test whether no race conditions are reported on std::thread. Note: since
// the implementation of std::thread uses the shared pointer implementation,
// that implementation has to be annotated in order to avoid false positives.
// See also http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html for more
// information.

#include "../../drd/drd.h"
#define _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(addr) \
  ANNOTATE_HAPPENS_BEFORE(addr)
#define _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(addr) \
  ANNOTATE_HAPPENS_AFTER(addr)
#define _GLIBCXX_EXTERN_TEMPLATE -1

#include <iostream>
#include <thread>

int main(int argc, char** argv)
{
  std::thread t( []() { } );
  t.join();
  std::cerr << "Done.\n";
  return 0;
}

[Valgrind-users] cannot get Helgrind/DRD work with C++11 thread

[Dave O. <dav...@gm...>]

Hi,

I posted yesterday a question to stackoverflow regarding problems I am
having with Helgrind/DRD and C++11 thread:

http://stackoverflow.com/questions/24060626/cannot-get-helgrind-drd-work-with-c11-thread

but got no answer.

Any help here?

-- dave

Re: [Valgrind-users] statespace analysis with Valgrind

[Stanislav B. <sta...@vs...>]

I am sorry that I oversimplified my example, but I am not going to 
enumerate all possible value of 32b-integer. I am aware of the 
state-space explosion problem. My nondeterminism comes from 
communication between processes and such state-space can be efficiently 
pruned by partial-order reduction methods for many practical examples. 
But I did not want to complicate the description of my problem in 
Valgrind. I am also interested in concrete values; therefore I am not 
interested in abstract interpretation or other static analytical methods.

Thank you for the reply,
Stanislav Bohm


On 06/04/2014 12:39 AM, Ben Stanley wrote:
> This idea sounds a little bit like Polyspace, which performs static 
> code analysis.
>
> http://www.mathworks.com.au/products/polyspace/
>
> Polyspace performs static analysis on the code using interval 
> arithmetic, and looks for domain errors on type conversions, division 
> by an interval containing 0, and many other things.
>
> I do not know of any open source equivalent for this process.
>
> I am concerned that it will not be feasible to perform this analysis 
> at run time due to the combinatorial explosion of states that you will 
> encounter. For instance, consider the possible number of states with 
> just two 32 bit integer variables. Polyspace copes with this by 
> lumping many states together as an interval. It can also cope with 
> disjoint sets.
>
> I am sorry that I cannot help you with how to do this in valgrind. I 
> hope others can contribute there.
>
> I do not represent the Mathworks, but I have done the training course 
> for their Polyspace product.
>
> Ben Stanley
>
>
> On 4 June 2014 5:08:28 AM Stanislav Bohm <sta...@vs...> wrote:
>
>> Hello,
>>
>> I plan to build an experimental tool and I am considering to build my 
>> work on Valgrind. Hence I would like to ask you for comments, if my 
>> idea is feasible. I plan to build a dynamic verifier of C/C++ 
>> programs with a non-deterministic behaviour (e.g. MPI programs). 
>> Generally I want to explore all possible runs of a program in a 
>> single run.
>>
>> I would like to achieve something like this.
>>
>> int main()
>> {
>>      int x = nondeterministic_choice(0, 1); // set to x 0 or 1
>>      if (x > 0) {
>>         printf("%i\n", x);
>>      }
>>      return 0;
>> }
>>
>> When the program arrives to nondeterministic_choice, its state is 
>> remembered and the program continues with the first choice (x=0). 
>> When it terminates, the program returns to the saved position and the 
>> execution continues with x=1. (I am now interested only in single 
>> threaded programs that do not communicate with the system.)
>>
>> I do not want to simply use system "fork", because I am expecting a 
>> large number of branching and I want to understand a memory layout to 
>> have possibility to merge executions.
>>
>> As far I understand Valgrind implementation, I can implement my idea 
>> as Valgrind tool like this:
>>
>> - nondeterministic_choice is the client request. It stores the 
>> current state of thread (everything in struct ThreadState) and then 
>> it continues with the first choice of nondeterministic_choice.
>> - The memory in the the following run can be monitored in a similar 
>> way as in memcheck. It allows to implemented a copy-on-write 
>> mechanism and backup changed memory.
>> - When the program terminates, the thread state and changed memory 
>> will be restored to the point when it was saved and the another path 
>> is executed.
>>
>> I would like to ask you for any comments but I have also the 
>> following questions:
>> - It is sufficient to backup struct ThreadState (and its members) + 
>> memory state to fully catch program state in a restorable form?
>> - It is possible to set a callback (in Valgrind tool) for an event 
>> directly after program termination (return in main/exit call), but 
>> still have Valgrind in a fully functional form, where I can restore 
>> my saved thread and normally continue in computation.
>>
>> Thank you,
>> Stanislav Bohm
>>
>>
>> ------------------------------------------------------------------------------ 
>>
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and 
>> their applications. Written by three acclaimed leaders in the field, 
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>

Re: [Valgrind-users] statespace analysis with Valgrind

[Ben S. <Ben...@ex...>]

This idea sounds a little bit like Polyspace, which performs static code 
analysis.

http://www.mathworks.com.au/products/polyspace/

Polyspace performs static analysis on the code using interval arithmetic, 
and looks for domain errors on type conversions, division by an interval 
containing 0, and many other things.

I do not know of any open source equivalent for this process.

I am concerned that it will not be feasible to perform this analysis at run 
time due to the combinatorial explosion of states that you will encounter. 
For instance, consider the possible number of states with just two 32 bit 
integer variables. Polyspace copes with this by lumping many states 
together as an interval. It can also cope with disjoint sets.

I am sorry that I cannot help you with how to do this in valgrind. I hope 
others can contribute there.

I do not represent the Mathworks, but I have done the training course for 
their Polyspace product.

Ben Stanley


On 4 June 2014 5:08:28 AM Stanislav Bohm <sta...@vs...> wrote:

> Hello,
>
> I plan to build an experimental tool and I am considering to build my work 
> on Valgrind. Hence I would like to ask you for comments, if my idea is 
> feasible. I plan to build a dynamic verifier of C/C++ programs with a 
> non-deterministic behaviour (e.g. MPI programs). Generally I want to 
> explore all possible runs of a program in a single run.
>
> I would like to achieve something like this.
>
> int main()
> {
>      int x = nondeterministic_choice(0, 1); // set to x 0 or 1
>      if (x > 0) {
>         printf("%i\n", x);
>      }
>      return 0;
> }
>
> When the program arrives to nondeterministic_choice, its state is 
> remembered and the program continues with the first choice (x=0). When it 
> terminates, the program returns to the saved position and the execution 
> continues with x=1. (I am now interested only in single threaded programs 
> that do not communicate with the system.)
>
> I do not want to simply use system "fork", because I am expecting a large 
> number of branching and I want to understand a memory layout to have 
> possibility to merge executions.
>
> As far I understand Valgrind implementation, I can implement my idea as 
> Valgrind tool like this:
>
> - nondeterministic_choice is the client request. It stores the current 
> state of thread (everything in struct ThreadState) and then it continues 
> with the first choice of nondeterministic_choice.
> - The memory in the the following run can be monitored in a similar way as 
> in memcheck. It allows to implemented a copy-on-write mechanism and backup 
> changed memory.
> - When the program terminates, the thread state and changed memory will be 
> restored to the point when it was saved and the another path is executed.
>
> I would like to ask you for any comments but I have also the following 
> questions:
> - It is sufficient to backup struct ThreadState (and its members) + memory 
> state to fully catch program state in a restorable form?
> - It is possible to set a callback (in Valgrind tool) for an event directly 
> after program termination (return in main/exit call), but still have 
> Valgrind in a fully functional form, where I can restore my saved thread 
> and normally continue in computation.
>
> Thank you,
> Stanislav Bohm
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their 
> applications. Written by three acclaimed leaders in the field, this first 
> edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] statespace analysis with Valgrind

[Stanislav B. <sta...@vs...>]

Hello,

I plan to build an experimental tool and I am considering to build my 
work on Valgrind. Hence I would like to ask you for comments, if my idea 
is feasible. I plan to build a dynamic verifier of C/C++ programs with a 
non-deterministic behaviour (e.g. MPI programs). Generally I want to 
explore all possible runs of a program in a single run.

I would like to achieve something like this.

int main()
{
     int x = nondeterministic_choice(0, 1); // set to x 0 or 1
     if (x > 0) {
        printf("%i\n", x);
     }
     return 0;
}

When the program arrives to nondeterministic_choice, its state is 
remembered and the program continues with the first choice (x=0). When 
it terminates, the program returns to the saved position and the 
execution continues with x=1. (I am now interested only in single 
threaded programs that do not communicate with the system.)

I do not want to simply use system "fork", because I am expecting a 
large number of branching and I want to understand a memory layout to 
have possibility to merge executions.

As far I understand Valgrind implementation, I can implement my idea as 
Valgrind tool like this:

- nondeterministic_choice is the client request. It stores the current 
state of thread (everything in struct ThreadState) and then it continues 
with the first choice of nondeterministic_choice.
- The memory in the the following run can be monitored in a similar way 
as in memcheck. It allows to implemented a copy-on-write mechanism and 
backup changed memory.
- When the program terminates, the thread state and changed memory will 
be restored to the point when it was saved and the another path is 
executed.

I would like to ask you for any comments but I have also the following 
questions:
- It is sufficient to backup struct ThreadState (and its members) + 
memory state to fully catch program state in a restorable form?
- It is possible to set a callback (in Valgrind tool) for an event 
directly after program termination (return in main/exit call), but still 
have Valgrind in a fully functional form, where I can restore my saved 
thread and normally continue in computation.

Thank you,
Stanislav Bohm

Re: [Valgrind-users] Problem in getting valgrind to run on android

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

> Few dynamically loaded libraries were statically linked to few other libraries.   After converting them to dynamic libraries, I am closer to detect memory problems.   Also, I had to turn on -g and avoid stripping the executable to get an accurate detection
> 
> However, this still dazzles me:
> 
> I still get this warning while running valgrind:
> --8925--   Considering /system/lib/libc.so ..
> --8925--   .. CRC mismatch (computed aedb52cb wanted eadc3e5a)
> --8925--    object doesn't have a symbol table
> 
> When I compute crc for /system/lib/libc.so externally, I get aedb52cb and the system under test doesn't contain libc anywhere else..  Where else is the executable picking libc from?  Output of strace relevant to libc given below

I don't know exactly.  grep'ping the valgrind source code for "CRC mismatch"
shows  coregrind/m_debuginfo/readelf.c  function open_debug_file() which is
called from find_debug_file() which is called from "Bool ML_(read_elf_debug_info)".
read_elf_debug_info() gets the "wanted" crc:
            /* Extract the CRC from the debuglink section */
            UInt crc = ML_(img_get_UInt)(debuglink_escn.img,
                                         debuglink_escn.ioff + crc_offset);
So run memcheck under a debugger, put a breakpoint there, look at the
traceback, and determine which debuglink section is being examined.

One common problem is "crosslinking": building the executable main program
on a different machine, especially one with a different hardware architecture,
such as building an ARM executable using a x86* development environment.
The two libc.so must match in order that valgrind sees the right symbols,
but it is easy for the target machine and the build machine
to get out-of-sync: one gets updated but not the other.

Re: [Valgrind-users] Problem in getting valgrind to run on android

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

On 02/06/14 15:05, Vignesh wrote:

> However, this still dazzles me:
>
> I still get this warning while running valgrind:
> --8925--   Considering /system/lib/libc.so ..
> --8925--   .. CRC mismatch (computed aedb52cb wanted eadc3e5a)
> --8925--    object doesn't have a symbol table
>
> When I compute crc for /system/lib/libc.so externally, I get aedb52cb
> and the system under test doesn't contain libc anywhere else..  Where
> else is the executable picking libc from?  Output of strace relevant to
> libc given below

It's not the CRC of libc.so you want, it's the CRC of the debug file.

So your libc.so apparently has a .gnu_debuglink section in it which says 
that there should be a debug image with a CRC of eadc3e5a.

The slightly odd thing is that your strace suggests it isn't finding a 
debug image, so I'm not sure why it is calcing the CRC of the main file 
instead.

None the less, if you have built with a separate debug file then you 
need to install it so valgrind can find it.

Tom

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