Re: [Valgrind-users] Uninitialized access findings on non-static file scope variables that's been initialized?
On 08/12/15 22:18, Jeffrey Walton wrote: Its *really* pathetic the C++ language lacks a mechanism for me to say Object 1 depends upon String 1, 2, 3, and Object 2 depends upon Object 1 and String 1, 2, 3. What's wrong with the singleton pattern ? When using the singleton pattern non-circular dependencies are resolved at runtime without having to specify the dependencies explicitly to the compiler. Bart. -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Someone help clue me in on what DRD complaining about here?
On 05/27/15 19:42, Fred Smith wrote: Not sure I understand this diagnostic, or if I do, I don’t see how to solve it: ==00:00:00:16.486 30064== Conflicting store by thread 13 at 0x09440060 size 15 ==00:00:00:16.486 30064== at 0x4C2E147: free (vg_replace_malloc.c:476) ==00:00:00:16.486 30064== by 0x72EC938: tzset_internal (tzset.c:440) ==00:00:00:16.486 30064== by 0x72ED302: __tz_convert (tzset.c:629) ç ==00:00:00:16.486 30064== by 0x68FCE26: swill_serve_one (in /home/interface/interface/lib/libswill.so) ==00:00:00:16.486 30064== by 0x68FD384: swill_serve (in /home/interface/interface/lib/libswill.so) ==00:00:00:16.486 30064== by 0x41130E: HS_thr_ui (HS_ui.c:2336) ==00:00:00:16.486 30064== by 0x4C3024B: vgDrd_thread_wrapper (drd_pthread_intercepts.c:367) ==00:00:00:16.486 30064== by 0x7029DF4: start_thread (pthread_create.c:308) ==00:00:00:16.486 30064== by 0x73341AC: clone (clone.S:113) ==00:00:00:16.486 30064== Address 0x9440060 is at offset 0 from 0x9440060. Allocation context: ==00:00:00:16.487 30064== at 0x4C2D02D: malloc (vg_replace_malloc.c:299) ==00:00:00:16.487 30064== by 0x72C4529: strdup (strdup.c:42) ==00:00:00:16.487 30064== by 0x72EC940: tzset_internal (tzset.c:441) ç ==00:00:00:16.487 30064== by 0x72ED24F: tzset (tzset.c:597) ç ==00:00:00:16.487 30064== by 0x72EBD68: mktime (mktime.c:588) ==00:00:00:16.487 30064== by 0x40B571: wait_til_time (HS_gc.c:105) ==00:00:00:16.487 30064== by 0x40B727: HS_thr_gc (HS_gc.c:204) ==00:00:00:16.487 30064== by 0x4C3024B: vgDrd_thread_wrapper (drd_pthread_intercepts.c:367) ==00:00:00:16.487 30064== by 0x7029DF4: start_thread (pthread_create.c:308) ==00:00:00:16.487 30064== by 0x73341AC: clone (clone.S:113) ==00:00:00:16.487 30064== Other segment start (thread 12) ==00:00:00:16.487 30064== at 0x4C33AA3: pthread_mutex_unlock_intercept (drd_pthread_intercepts.c:692) ==00:00:00:16.487 30064== by 0x4C33AA3: pthread_mutex_unlock (drd_pthread_intercepts.c:700) ==00:00:00:16.487 30064== by 0x448635: HS_procmgr_mutex_unlock (HS_procwatch.c:56) ==00:00:00:16.487 30064== by 0x4487C6: HS_log_pid (HS_procwatch.c:134) ==00:00:00:16.487 30064== by 0x40B6ED: HS_thr_gc (HS_gc.c:177) ==00:00:00:16.487 30064== by 0x4C3024B: vgDrd_thread_wrapper (drd_pthread_intercepts.c:367) ==00:00:00:16.487 30064== by 0x7029DF4: start_thread (pthread_create.c:308) ==00:00:00:16.487 30064== by 0x73341AC: clone (clone.S:113) ==00:00:00:16.487 30064== Other segment end (thread 12) ==00:00:00:16.487 30064== at 0x4C32DB3: pthread_mutex_lock_intercept (drd_pthread_intercepts.c:642) ==00:00:00:16.487 30064== by 0x4C32DB3: pthread_mutex_lock (drd_pthread_intercepts.c:647) ==00:00:00:16.487 30064== by 0x40B58F: wait_til_time (HS_gc.c:111) ==00:00:00:16.487 30064== by 0x40B727: HS_thr_gc (HS_gc.c:204) ==00:00:00:16.487 30064== by 0x4C3024B: vgDrd_thread_wrapper (drd_pthread_intercepts.c:367) ==00:00:00:16.487 30064== by 0x7029DF4: start_thread (pthread_create.c:308) ==00:00:00:16.487 30064== by 0x73341AC: clone (clone.S:113) ==00:00:00:16.487 30064== The “allocation context” is a different thread than where the conflict is reported. The only commonality I can see is that they both are calling tz* routines. The mktime man page indicates it stores a value in the tzname variable. All I can figure out from this report is that DRD thinks tzname belongs to the “allocation context” and so whines when its used elsewhere. Am I overlooking something here? Is there some other function I should be using (in multithreaded programs) instead of mktime() ?? Thanks in advance! Please try to add a call to
Re: [Valgrind-users] Assertion 'DRD_(g_threadinfo)[tid].pt_threadid != INVALID_POSIX_THREADID' failed.
On 02/21/15 01:08, Joe VanAndel wrote: I am using valgrind 3.10.1 (I get the same results building valgrind from SVN). My program uses boost 1_57_0, and Wt 3-3-4-rc1. I am compiling with gcc 4.8.2 on CentOS 7.0.1406 When I run my program under valgrind —tool=drd, valgrind aborts with the attached message. I have several questions: 1) If this is a real error in my code, Wt, or Boost, how would I find and fix the error? 2) Does anyone routinely use the boost DRD tool with Wt and Boost, or with Boost? drd: drd_thread.c:630 (vgDrd_thread_entering_pthread_create): Assertion 'DRD_(g_threadinfo)[tid].pt_threadid != INVALID_POSIX_THREADID' failed. host stacktrace: ==21016==at 0x38046C68: show_sched_status_wrk (m_libcassert.c:319) ==21016==by 0x38046D84: report_and_quit (m_libcassert.c:390) ==21016==by 0x38046F11: vgPlain_assert_fail (m_libcassert.c:456) ==21016==by 0x3803639B: vgDrd_thread_entering_pthread_create (drd_thread.c:630) ==21016==by 0x3802AC6B: handle_client_request (drd_clientreq.c:295) ==21016==by 0x3805E1E0: wrap_tool_handle_client_request (m_tooliface.c:280) ==21016==by 0x38097C9F: do_client_request (scheduler.c:2074) ==21016==by 0x38097C9F: vgPlain_scheduler (scheduler.c:1407) ==21016==by 0x380A687C: thread_wrapper (syswrap-linux.c:103) ==21016==by 0x380A687C: run_a_thread_NORETURN (syswrap-linux.c:156) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==21016==at 0x4C2F5B9: vgDrd_entering_pthread_create (drd_pthread_intercepts.c:331) ==21016==by 0x4C2F5B9: pthread_create_intercept (drd_pthread_intercepts.c:484) ==21016==by 0x4C2F5B9: pthread_create@* (drd_pthread_intercepts.c:501) ==21016==by 0x5C14C38: boost::thread::start_thread_noexcept() (in /usr/local/boost_1_57_0/lib/libboost_thread-mt.so.1.57.0) ==21016==by 0x6A6975: boost::thread::start_thread() (thread.hpp:179) This might be a bug in the Valgrind core. When a thread is created the Valgrind core invokes drd_pre_thread_create(). That function calls DRD_(thread_pre_create)() which sets up the valgrind-to-DRD thread ID translation. The assertion failure above means that such a translation had not been set up before the code in the newly created thread started to run. If you can provide a small test program with which I can reproduce the above behavior I will have a look into this. The boost regression test that is present in the Valgrind source tree seems to work fine on CentOS 7.0.1046: $ ./vg-in-place --tool=drd drd/tests/boost_thread ==24662== drd, a thread error detector ==24662== Copyright (C) 2006-2013, and GNU GPL'd, by Bart Van Assche. ==24662== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info ==24662== Command: drd/tests/boost_thread ==24662== Thread 1. Thread 2. Finished. ==24662== ==24662== For counts of detected and suppressed errors, rerun with: -v ==24662== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 33 from 33) Bart. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] helgrind/drd in android(mips)
On 18/11/2014 23:33, Benny anam wrote: I try to figure out some problems about invalid free in android(mips) device, which may be caused by thread sync, I did as the README.android says compile the source and push to device, memcheck works fine in my device, but when I changed option to --tool=helgrind, the android logcat says the following: |I/start_valgrind.sh( 9328): link_image[2207]: 9329 couldnot load needed library '/data/local/Inst/lib/valgrind/vgpreload_drd-mips32-linux.so' for '/system/bin/app_process' (mips_relocate_got[1749]: 9329 cannot locate'sched_yield'...| but sched_yield is in /system/lib/libc.so. I use valgrind 3.10.0 and android 4.1 on mips, ndk-r8 and ndk-r10c both tried with the same results. So my question is helgrind/drd supported in android(arch mips) yet, If so, how can I make it work in my device? Thanks! Can you check whether Helgrind and/or DRD work if the sched_yield() call is changed into sleep(1) ? I'm not sure yet what's going on but this might be the quickest way to get these tools working. Bart. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] helgrind and threadsafe-statics
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.
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing Easy Data Exploration
http://www.hpccsystems.com
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] cannot get Helgrind/DRD work with C++11 thread
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.
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing Easy Data Exploration
http://www.hpccsystems.com
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] helgrind and threadsafe-statics
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. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] cannot get Helgrind/DRD work with C++11 thread
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. -- 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] cannot get Helgrind/DRD work with C++11 thread
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. -- 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Performance debugging of Linux process scheduling
On 01/08/14 08:34, Alireza Haghdoost wrote: Ideally, I can put my application threads to specific CPU cores. Then I need a performance monitoring tool which tells me what other processes has been executed on these CPU cores during the execution of my application. Does Valgrind a tool to help me out ? Valgrind is a great suite of tools for analyzing the behavior of a single process. There are other tools that help with system-wide performance analysis. On Linux e.g. the perf and ftrace tool allows to observe context switches, timer interrupt invocations and much more. The following may help: * Stefan Hajnoczi, How to use perf-probe, March 2011, Stefan's blog (http://blog.vmsplice.net/2011/03/how-to-use-perf-probe.html). * Jake Edge, A look at ftrace, March 2009, LWN.net (http://lwn.net/Articles/322666/). Bart. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] How to write a tool to check unsafe strcpy-alike functions in another way
On 31/10/2013 4:56, hamid alaei wrote: Hi everyone, Assume there is a C code that do this: char buff1[20]; char buff2[30]=some small string; ... strcpy(buff1, buff2); This code is can be regarded unsafe not only because it use strcpy(), which doesn't accept a size argument for the maximum capacity of buff1, but also because the maximum capacity if the target string buff1 is less than the maximum capacity of the src string buff2. I know that if strcpy() tries to write outside buff1, then memcheck or sgcheck can detect that, depending on whether these strings are in stack/global memory or in the heap. But I want a warning while calling strcpy() in this manner as well, regardless of whether overflow happens or not. I am wondering if there is such a tool to do so. I guess it should replace strcpy() and similar functions with a wrapper. Does anybody know suck a tool/extension or how to write such a wrapper that can have access to the max-size of buff1 and buff2? Hello Hamid, I think that smatch is already able to detect for the above example that the output buffer is too small (http://smatch.sourceforge.net/). Bart. -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] helgrind and atomic operations
On 08/25/12 08:45, David Faure wrote:
How do I tell helgrind that some atomic operations on integers are OK?
A suppression like this works, but it would make helgrind more useful to all
Qt users if either atomic operations were handled automatically, or if this
was added to valgrind's own suppressions.
{
qt5_basic_atomic_integer
Helgrind:Race
fun:_ZNK19QBasicAtomicIntegerIiE4loadEv
}
Also, this only works for integers, not for pointers...
==8489== Possible data race during read of size 8 at 0x8B9C968 by thread #3
==8489==at 0x57549C0: QBasicAtomicPointerQTextCodec::loadAcquire()
const (qgenericatomic.h:110)
==8489==by 0x5753A26: QTextCodec::codecForLocale() (qtextcodec.cpp:683)
==8489==by 0x558BD08: QString::toLocal8Bit() const (qstring.cpp:3959)
==8489==
==8489== This conflicts with a previous write of size 8 by thread #2
==8489==at 0x57549A2:
QBasicAtomicPointerQTextCodec::storeRelease(QTextCodec*)
(qgenericatomic.h:119)
==8489==by 0x5757D5D: QIcuCodec::defaultCodecUnlocked()
(qicucodec.cpp:441)
==8489==by 0x5753A43: QTextCodec::codecForLocale() (qtextcodec.cpp:687)
==8489==by 0x558BD08: QString::toLocal8Bit() const (qstring.cpp:3959)
Can't make suppressions for these, given that the template class could use
any type
(here QTextCodec).
The implementation of loadAcquire/storeRelease is compiler and platform
dependent.
With C++11 it uses std::atomic, with gcc (in non-c++11 mode) it uses some
__sync_synchronize stuff,
on ARM there's a bit of assembly, etc.
I presume all this is too low-level for helgrind? I.e. can it actually detect
atomic operations
and therefore validate Qt's implementation, or should we rather just trust
Qt and aim for
silencing helgrind whenever it sees QBasicAtomic{Integer,Pointer}?
The Qt authors will have to modify the Qt library somewhat before it
will become convenient to analyze Qt programs with Helgrind or DRD. See
also this bug report (created three years ago):
http://bugreports.qt-project.org/browse/QTBUG-5655.
Bart.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] DRD gives unexpected warnings
On 06/05/12 16:13, Christoph Bartoschek wrote: So I wonder how there can be a data race for writing to data. The memory has been just allocated and no other thread knows about it. How can this happen? Should have been fixed in r12629. Bart. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] DRD gives unexpected warnings
On 06/06/12 07:56, Christoph Bartoschek wrote: Am 05.06.2012 20:12, schrieb Christoph Bartoschek: How can this happen? Was that output produced by Valgrind 3.7.0 ? If so, do you get the same output if you build Valgrind from the SVN trunk ? Yes it was from 3.7.0. I start a run with SVN trunk. It takes about 20 hours. The first errors show up and I see the same problem. A race is reported for memory that has just been allocated and is now filled. It would help if you could have a look at the assembly code generated by the compiler to see if the compiler really calls malloc at that point - maybe some header file has redefined malloc such that it allocates memory from a memory pool that has not been instrumented for Valgrind. Also, which memory allocator are you using ? The one in glibc, tcmalloc or even another one ? Bart. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] DRD gives unexpected warnings
On 06/05/12 16:13, Christoph Bartoschek wrote:
I get the following race from DRD:
Conflicting store by thread 7 at 0x55fe8aa0 size 8
by 0x5CCD8750: func() (inv_utils.C:1711)
by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x5047F04: start_thread (in /lib64/libpthread-2.14.1.so)
by 0x5CB710C: clone (in /lib64/libc-2.14.1.so)
Address 0x55fe8aa0 is at offset 0 from 0x55fe8aa0. Allocation context:
at 0x4C2BC9D: malloc (in
/usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x5CCD849F: func() (inv_utils.C:1690)
by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x5047F04: start_thread (in /lib64/libpthread-2.14.1.so)
by 0x5CB710C: clone (in /lib64/libc-2.14.1.so)
Other segment start (thread 6)
at 0x4C31712: pthread_spin_lock (in
/usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x22C031FD: hunc (bn_thread.C:43)
by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x5047F04: start_thread (in /lib64/libpthread-2.14.1.so)
by 0x5CB710C: clone (in /lib64/libc-2.14.1.so)
Other segment end (thread 6)
at 0x4C30EC2: pthread_spin_init (in
/usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x22C032AD: hunc (bn_thread.C:47)
by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x5047F04: start_thread (in /lib64/libpthread-2.14.1.so)
by 0x5CB710C: clone (in /lib64/libc-2.14.1.so)
The function func() is in essence:
{
int * data = malloc(100);
for (int i = 0; i != 100; ++i) {
data[i] = 0; --- Line 1711
}
// Some small calculations
free(data);
}
So I wonder how there can be a data race for writting to data. The
memory has been just allocated and no other thread knows about it.
How can this happen?
Was that output produced by Valgrind 3.7.0 ? If so, do you get the same
output if you build Valgrind from the SVN trunk ?
Bart.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind config unable to detect boost...
On 04/18/12 14:28, Plug Gulp wrote: Even though Boost development libraries are installed on my system, the configure script fails to detect it. Does trunk r12507 help ? Bart. -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Hard to interpret the race
On 03/13/12 14:47, Panagiotis Foteinos wrote:
Hello grinders.
So, I find it difficult to see the race. Below, the valgrind DRD output
follows:
**
Conflicting load by thread 1 at 0x1221c91c size 4
==4907==at 0x5B7028: Parallel_Mesh_Generation::try_lock(Vertex*,
int) (Parallel_Mesh_Generation.cxx:2224)
..
Other segment start (thread 9)
==4907==at 0x4C352A0: pthread_mutex_unlock (drd_pthread_intercepts.c:665)
==4907==by 0x5CB1E9: boost::mutex::unlock() (mutex.hpp:61)
==4907==by 0x5C96DE: Parallel_Mesh_Generation::UpdateNewCells(int,
Simple_Containers::VectorCell*) (Parallel_Mesh_Generation.cxx:8909)
==4907==by 0x5B3FC7: Parallel_Mesh_Generation::client_insert(int
const, Point const, Cell*) (Parallel_Mesh_Generation.cxx:790)
Other segment end (thread 9)
==4907==at 0x6E13464: __lll_lock_wait (lowlevellock.S:136)
==4907==by 0x6E0E5D8: _L_lock_953 (pthread_mutex_lock.c:117)
==4907==by 0x6E0E3F9: pthread_mutex_lock (pthread_mutex_lock.c:61)
==4907==by 0x4C362AF: pthread_mutex_lock (drd_pthread_intercepts.c:614)
==4907==by 0x5CB182: boost::mutex::lock() (mutex.hpp:52)
==4907==by 0x5C9661: Parallel_Mesh_Generation::UpdateNewCells(int,
Simple_Containers::VectorCell*) (Parallel_Mesh_Generation.cxx:8900)
==4907==by 0x5B3FC7: Parallel_Mesh_Generation::client_insert(int
const, Point const, Cell*) (Parallel_Mesh_Generation.cxx:790)
**
According to DRD, there is a race when thead 1 is at line 2224, and
thread 9 is at the lines 8900-8909, correct?
Below, the relevant code lines are attached:
**
Thread 1:
if(v-thread_id == thread_id)
//line 2224
**
and
**
Thread 9:
this-utilization_mtx.lock();
//line 8900
if(this-threads_without_work != 0)
{
this-threads_without_work--;
#ifdef REPORT_COUNTERS
(*this-begging_list_not_empty[thread_id])++;
#endif
other_id =
this-beggers[(this-beg_index_start++)%this-number_of_threads];
this-utilization_mtx.unlock(); //line
8909
**
The variable thread_id in Thread 9 is local to its stack. It has
nothing to do with either v-thread_id or thread_id of Thread 1.
Is this a false positive, or the drd message says something else?
It might be a race on v or v-thread_id as well. A convenient way to
analyze this further is to insert DRD_TRACE_VAR(thread_id) in the
constructor of the object v points at and to insert
DRD_TRACE_VAR(thread_id) just after the declaration of the thread_id
stack variable(s).
Bart.
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] cross-compile valgrind-3.7.0
On Wed, Jan 11, 2012 at 9:23 AM, Brilliantov Kirill Vladimirovich brillian...@byterg.ru wrote: configure: error: please use gcc = 3.0 or clang = 2.9 How can I solve this problem? It's a bug in the configure script. You can either modify the gcc version check in configure.in or check out the Valgrind svn trunk r12327 or later. Bart. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] virtual inheritance and race conditions
On Mon, Jan 9, 2012 at 2:45 PM, Joris Koster joris.kos...@aimms.com wrote: joris@grazer:~/tmp/src$ valgrind --version valgrind-3.6.1-Debian In the 3.7.0 release notes you can see that the following bug has been fixed: 243935 Helgrind: incorrect handling of ANNOTATE_HAPPENS_BEFORE()/AFTER() Bart. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] virtual inheritance and race conditions
On Fri, Jan 6, 2012 at 4:04 PM, Joris Koster joris.kos...@aimms.com wrote:
void releaseRef() {
int nRefCnt = __sync_add_and_fetch(m_nRefCnt, -1);
if (nRefCnt == 0) {
delete this;
}
}
Please read the documentation of ANNOTATE_HAPPENS_BEFORE() and
ANNOTATE_HAPPENS_AFTER() in the Valgrind documentation first.
Thanks,
Bart.
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] The question I met when compiling the valgrind
2011/11/28 奕楠 邱 magicmcgrad...@hotmail.com: In this website https://bugs.kde.org/show_bug.cgi?id=270777 It teaches me how to compile the MIPS version valgrind It need to download some patches and make some modification like this: $ svn export -r 12270 svn://svn.valgrind.org/valgrind/trunk $ cd trunk $ patch -p0 ../existing_files_r12270_mips.diff $ patch -p0 ../new_files_r12270_mips_A.diff $ patch -p0 ../new_files_r12270_mips_B.diff $ ./autogen.sh $ ./configure $ make $ make install when I run the ./autogen.sh then it shows this error Please add that information to the KDE bugzilla entry mentioned above. Bart. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] hello, I have some question about compilation
2011/11/24 奕楠 邱 magicmcgrad...@hotmail.com Sorry, recently, my research topic need the support of valgrind tool so, can I put the valgrind source code onto another platform and compile it? there is a multicore platform named tile64 http://en.wikipedia.org/wiki/TILE64 This might help: https://bugs.kde.org/show_bug.cgi?id=270777. Cross-compilation is supported. Bart. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Question about using valgrind on a FreeBSD 8.0 system with a Myri Ethernet Card
2011/10/6 Mustafa Reşit Şahin resitsa...@gmail.com I am trying to run Valgrind on a FreeBSD 8.0 system with a Myri ethernet card. This mailing list is read by users and developers of the official Valgrind ports (Linux and Darwin). I'm not sure this list is read by users and/or developers of the FreeBSD Valgrind port. There might be a more appropriate mailing list for your question. More information can be found here: http://www.freebsd.org/cgi/ports.cgi?query=valgrind. Bart. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] helgrind and double checked initialization
On Sun, Aug 28, 2011 at 5:44 AM, Jeffrey Walton noloa...@gmail.com wrote:
I want to use double checked initialization for a program, but I'm
catching some warnings from helgrind. A typical use is shown below.
Its kind of tedious to run --gen-suppressions=yes for to develop
suppressions. Plus, the suppression rules are only applicable to the
current name mangling scheme.
Is there a helgrind friendly way to write the initialization so that I
don't get a warning?
One option is to implement the ANNOTATE_IGNORE_*_{BEGIN,END} macros in
Helgrind (see also helgrind/helgrind.h), another option is to use a
data race detection tool in which these macros are implemented.
Bart.
--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] helgrind and double checked initialization
On Sun, Aug 28, 2011 at 2:32 PM, Milian Wolff m...@milianw.de wrote: On Saturday 27 August 2011 23:44:02 Jeffrey Walton wrote: I want to use double checked initialization for a program, but I'm catching some warnings from helgrind. A typical use is shown below. Its kind of tedious to run --gen-suppressions=yes for to develop suppressions. Plus, the suppression rules are only applicable to the current name mangling scheme. Is there a helgrind friendly way to write the initialization so that I don't get a warning? Reading http://en.wikipedia.org/wiki/Double-checked_locking I'd think that the warnings are valid - no? Only MSVC apparently interpretes volatile in a way that would make this a safe pattern in C++. It depends. If a memory barrier is present between initialization of the allocated structure and assignment to the variable init, the code posted by Jeffrey should be safe even without init having been declared volatile. Bart. -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] helgrind and double checked initialization
On Sun, Aug 28, 2011 at 6:55 PM, Jeffrey Walton noloa...@gmail.com wrote: On Sun, Aug 28, 2011 at 12:26 PM, Bart Van Assche bvanass...@acm.org wrote: On Sun, Aug 28, 2011 at 6:13 PM, Jeffrey Walton noloa...@gmail.com wrote: (1) Never trust wikipedia. Reading your message makes me wonder whether you are familiar with the reason why memory barriers exist, I'm not aware that GCC will change the semantics of the program under these conditions. I could be wrong, though. What matters here is that without intervening memory barrier store instructions executed by one CPU may be observed in the opposite order by another CPU. This won't happen with x86 CPUs but can happen with e.g. PowerPC and ARM CPUs. When implementing the double-checked locking pattern, one has not only to be careful about instruction reordering by the compiler but also about reordering by the memory subsystem. something the Wikipedia authors of the page about double-checked locking clearly are aware of ? It does not change the fact that I do not trust wikipedia. I've found too many mistakes of the years. :-) Bart. -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind for ARM 1176 for linux
On Wed, Jul 20, 2011 at 9:24 PM, Mudric, Dusan (Dusan) dmud...@avaya.comwrote: I forgot to mention one more fact. I am using NFS mount. /etc/fstab: 47.135.159.188:/exports /exports nfs intr,noauto,nolock 0 0 Here is the valgrind ls -l output. If started as NFS mounted, nothing happens: 47.134.206.85 # pwd /exports 47.134.206.85 # ls Valgrind 47.134.206.85 # cd Valgrind/ 47.134.206.85 # ls bin include lib share valgrind 47.134.206.85 # ./valgrind ls -l If I copy valgrind executable on the target, valgrind ls -l prints something: 47.134.206.85 # ./valgrind ls -l valgrind: failed to start tool 'memcheck' for platform 'arm-linux': No such file or directory Problem is that I can not put the whole Valgrind on the target. It is 80MB big and I don't have that much RAM available. Does it mean that valgrind can not run with NFS mount? It means that Valgrind has not been configured or installed correctly. Please have a look at README.android on the trunk for an example of how to configure and install Valgrind when cross-compiling. Bart. -- 5 Ways to Improve Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Annoying Malloc Seg Fault
On Fri, Jun 17, 2011 at 5:45 PM, Stephanie Stroka
stephanie.str...@salzburgresearch.at wrote:
My code at that position looks like this:
284 static uint* sort(uint** matrix, uint width, uint height) {
285 uint* data = (uint*) malloc(width * height * sizeof(uint));
286 uint i,j=0;
287 for(i=0; iheight; i++) {
288 for(j=0; jwidth; j++) {
289 data[j + i*height] = matrix[i][j];
290 }
291 }
The above won't crash if height is less than or equal to width, but if
height is larger than width it will crash. Haven't you noticed yet
what is wrong with the above code ?
Bart.
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] valgrind + LLVM/clang 2.9: line information, client requests
On Wed, Apr 20, 2011 at 10:35 AM, Julian Seward jsew...@acm.org wrote: * Line information is missing in valgrind report. That works when compiling with gcc. Yes, I noticed that too. I haven't investigated. btw, you should have a look at https://bugs.kde.org/show_bug.cgi?id=242137, which is also related to a LLVM+Valgrind issue. * clang complains about return value not ignored as it should be when using the client request macros in the code (-Wall -Werror). Does that still happen with a Valgrind svn trunk build? I thought Bart did some fixes in that area. Or proposed some fixes. Or something like that. The patch attached to https://bugs.kde.org/show_bug.cgi?id=242137 still triggers return value not ignored as it should be with gcc 4.4 and before. I'll update that patch such that these warnings are gone too. Bart. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind Feature Query: Storage Driver Testing
On Wed, Mar 30, 2011 at 5:49 PM, Skindell, David david.pat.skind...@hp.comwrote: *From:* Skindell, David *Sent:* Wednesday, March 30, 2011 10:47 AM *To:* 'valgrind-users@lists.sourceforge.net' *Subject:* Valgrind Feature Query: Storage Driver Testing Just trying to find out if Valgrind can be used to monitor/test a storage device driver, or any device driver and/or Linux service. If anyone knows the yes/no answer or even direct me to an example, it’d be much appreciated. Hello David, If you want to develop a kernel-mode storage driver, the proper way to develop such a driver (just like any other driver) is to make its operation easily verifiable via source reading (a.k.a. cleanroom programming). If you are not familiar yet with kernel development then you are probably better off developing your driver in user space. Both the STGThttp://stgt.sourceforge.net/and the SCST http://scst.sourceforge.net/ projects support user-mode storage drivers. Bart. -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] gcc 4.6.0 - set but not used warnings
On Tue, Mar 29, 2011 at 12:24 PM, Bart Van Assche bvanass...@acm.org wrote: On Mon, Mar 28, 2011 at 11:14 PM, Julian Seward jsew...@acm.org wrote: On Monday, March 28, 2011, Bart Van Assche wrote: On Mon, Mar 28, 2011 at 6:32 PM, Julian Seward jsew...@acm.org wrote: On Monday, March 28, 2011, Piotr Jaroszyński wrote: I think the proper solution is to add __attribute__((unused)) to _qzz_res. What do you think? Yes. I just committed exactly such cleanups (r11673). Could you try it, to see if that also makes your compiles quiet again? Strange - I still see such warnings with r11673 while building the regression tests: Should be considerably improved, although not perfect, when building the regtests now. (at r 11675). The approach followed so far -- adding __attribute__((unused)) to unused variables used to store client request results -- has an important benefit, that is that the API for invoking client requests is preserved. Has the following already been considered: - Define a new facility for invoking client requests, e.g. VALGRIND_DO_CLIENT_REQUEST_E(), in such a way that it yields the result value of the client request instead of assigning that result value to a variable. It's not yet clear to me whether such a facility should be defined as a macro that uses a statement expression or as an inline function. - Redefine the existing macro VALGRIND_DO_CLIENT_REQUEST() such that it uses the new facility. - Replace invocations of VALGRIND_DO_CLIENT_REQUEST() in tools by VALGRIND_DO_CLIENT_REQUEST_E(). This transformation will allow to eliminate unused res variables instead of having to annotate them with __attribute__((unused)). A patch that implements the above is available here: https://bugs.kde.org/show_bug.cgi?id=269778. Suggestions for how to get rid of the new value computed is not used warnings are welcome. Bart. -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] gcc 4.6.0 - set but not used warnings
On Mon, Mar 28, 2011 at 6:32 PM, Julian Seward jsew...@acm.org wrote: On Monday, March 28, 2011, Piotr Jaroszyński wrote: I think the proper solution is to add __attribute__((unused)) to _qzz_res. What do you think? Yes. I just committed exactly such cleanups (r11673). Could you try it, to see if that also makes your compiles quiet again? Strange - I still see such warnings with r11673 while building the regression tests: [ ... ] custom_alloc.c: In function 'custom_alloc': custom_alloc.c:47:4: warning: variable '_qzz_res' set but not used [-Wunused-but-set-variable] [ ... ] Bart. -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] full path to source
Hello Ahmed, It's pretty easy to download the 3.6.1 source code from www.valgrind.org and to compile and install it. Any software developer should be able to do that. Bart. On Mon, Mar 21, 2011 at 7:11 PM, Osman, Ahmed ahmed_os...@mentor.com wrote: Thanks Bart but I'm using valgrind 3.5.0 and I don't see it -Original Message- From: bart.vanass...@gmail.com [mailto:bart.vanass...@gmail.com] On Behalf Of Bart Van Assche Sent: Friday, March 18, 2011 4:14 AM To: Osman, Ahmed Cc: valgrind-users@lists.sourceforge.net Subject: Re: [Valgrind-users] full path to source On Thu, Mar 17, 2011 at 11:59 PM, Osman, Ahmed ahmed_os...@mentor.com wrote: Is there a way to make valgrind report the full path of the source code? See also the documentation of --fullpath-after= here: http://www.valgrind.org/docs/manual/manual-core.html#manual-core.options. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] full path to source
On Thu, Mar 17, 2011 at 11:59 PM, Osman, Ahmed ahmed_os...@mentor.com wrote: Is there a way to make valgrind report the full path of the source code? See also the documentation of --fullpath-after= here: http://www.valgrind.org/docs/manual/manual-core.html#manual-core.options. Bart. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] DRD and --free-is-write bug-report
On Fri, Feb 4, 2011 at 12:16 PM, Andrea Mazzoleni amadva...@gmail.com wrote: I likely found a problem in the DRD when using the --free-is-write option. The following test case reports an huge amount of errors that are not expected. [ ... ] Sorry that it took so long, but I think I have found and fixed the problem that was present in the previous implementation of the --free-is-write option in DRD. The new implementation is present on the trunk in r11636. Please have a look at the documented limitations in the updated manual too. Bart. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind 3.6.0 on ppc doesn't detect any Invalid write errors
2011/3/9 Piotr Adaszyński adas...@gmail.com Strange. Does the output of make -s regtest on your setup match that of the nightly PPC build (available in the valgrind-developers mailing list archives) ? Unfortunately, it's impossible to run make -s regtest and perform regression tests on my target platform because of limited resources (no make, no perl etc.). Maybe the problem here is my processor ? It's MPC8548 (ppc e500) and I have to use gcc 3.4.x . gcc 3.4 should be fine, but don't think the PPC e500 is already supported by Valgrind. Bart. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] valgrind.h and C89 compilers
On Thu, Mar 3, 2011 at 4:28 PM, Tony Finch d...@dotat.at wrote:
We're preparing a release of Exim-4.75 which includes copies of valgrind.h
and memcheck.h from valgrind-3.6.0. This mostly fixed our portability
problems. Thanks!
Heiko Schlichting reported a problem compiling on Irix. Its compiler
doesn't support variable argument macros which means it chokes on the
following:
#if defined(NVALGRIND)
# define VALGRIND_PRINTF(...)
# define VALGRIND_PRINTF_BACKTRACE(...)
#else /* NVALGRIND */
I've stubbed it out in a fairly half-arsed manner since we don't use these
macros. I was hoping you guys might have a better fix.
Does the patch below help ?
Index: include/valgrind.h
===
--- include/valgrind.h (revision 11577)
+++ include/valgrind.h (working copy)
@@ -4415,13 +4415,6 @@
is the number of characters printed, excluding the **pid** part at the
start and the backtrace (if present). */
-#if defined(NVALGRIND)
-
-# define VALGRIND_PRINTF(...)
-# define VALGRIND_PRINTF_BACKTRACE(...)
-
-#else /* NVALGRIND */
-
#if !defined(_MSC_VER)
/* Modern GCC will optimize the static routine out if unused,
and unused attribute will shut down warnings about it. */
@@ -4434,6 +4427,9 @@
#endif
VALGRIND_PRINTF(const char *format, ...)
{
+#if defined(NVALGRIND)
+ return 0;
+#else /* NVALGRIND */
unsigned long _qzz_res;
va_list vargs;
va_start(vargs, format);
@@ -4452,6 +4448,7 @@
#endif
va_end(vargs);
return (int)_qzz_res;
+#endif /* NVALGRIND */
}
#if !defined(_MSC_VER)
@@ -4464,6 +4461,9 @@
#endif
VALGRIND_PRINTF_BACKTRACE(const char *format, ...)
{
+#if defined(NVALGRIND)
+ return 0;
+#else /* NVALGRIND */
unsigned long _qzz_res;
va_list vargs;
va_start(vargs, format);
@@ -4482,11 +4482,10 @@
#endif
va_end(vargs);
return (int)_qzz_res;
+#endif /* NVALGRIND */
}
-#endif /* NVALGRIND */
-
/* These requests allow control to move from the simulated CPU to the
real CPU, calling an arbitary function.
--
Free Software Download: Index, Search Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] valgrind.h and C89 compilers
On Thu, Mar 3, 2011 at 7:28 PM, Tony Finch d...@dotat.at wrote:
On Thu, 3 Mar 2011, Bart Van Assche wrote:
Does the patch below help ?
Mostly, except it exposes an __attribute__ clause which also upsets
standard-C compilers.
I did the following patch which has the disadvantage of causing warnings
about expressions without side-effects.
[ ... ]
Does the second version of this patch (see below) work better ?
Index: include/valgrind.h
===
--- include/valgrind.h (revision 11577)
+++ include/valgrind.h (working copy)
@@ -4415,14 +4415,7 @@
is the number of characters printed, excluding the **pid** part at the
start and the backtrace (if present). */
-#if defined(NVALGRIND)
-
-# define VALGRIND_PRINTF(...)
-# define VALGRIND_PRINTF_BACKTRACE(...)
-
-#else /* NVALGRIND */
-
-#if !defined(_MSC_VER)
+#if defined(__GNUC__) || defined(__INTEL_COMPILER)
/* Modern GCC will optimize the static routine out if unused,
and unused attribute will shut down warnings about it. */
static int VALGRIND_PRINTF(const char *format, ...)
@@ -4434,6 +4427,9 @@
#endif
VALGRIND_PRINTF(const char *format, ...)
{
+#if defined(NVALGRIND)
+ return 0;
+#else /* NVALGRIND */
unsigned long _qzz_res;
va_list vargs;
va_start(vargs, format);
@@ -4452,9 +4448,10 @@
#endif
va_end(vargs);
return (int)_qzz_res;
+#endif /* NVALGRIND */
}
-#if !defined(_MSC_VER)
+#if defined(__GNUC__) || defined(__INTEL_COMPILER)
static int VALGRIND_PRINTF_BACKTRACE(const char *format, ...)
__attribute__((format(__printf__, 1, 2), __unused__));
#endif
@@ -4464,6 +4461,9 @@
#endif
VALGRIND_PRINTF_BACKTRACE(const char *format, ...)
{
+#if defined(NVALGRIND)
+ return 0;
+#else /* NVALGRIND */
unsigned long _qzz_res;
va_list vargs;
va_start(vargs, format);
@@ -4482,11 +4482,10 @@
#endif
va_end(vargs);
return (int)_qzz_res;
+#endif /* NVALGRIND */
}
-#endif /* NVALGRIND */
-
/* These requests allow control to move from the simulated CPU to the
real CPU, calling an arbitary function.
--
Free Software Download: Index, Search Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind 3.6.0 on ppc doesn't detect any Invalid write errors
2011/3/1 Piotr Adaszyński adas...@gmail.com [ ... ] Could you tell me why results from ppc target are different ? What could I do wrong ? Strange. Does the output of make -s regtest on your setup match that of the nightly PPC build (available in the valgrind-developers mailing list archives) ? Bart. -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] DRD and --free-is-write bug-report
On Mon, Feb 7, 2011 at 9:28 AM, Konstantin Serebryany konstantin.s.serebry...@gmail.com wrote: On Sun, Feb 6, 2011 at 10:14 PM, Bart Van Assche bvanass...@acm.orgwrote: On Sat, Feb 5, 2011 at 5:54 PM, Konstantin Serebryany konstantin.s.serebry...@gmail.com wrote: On Sat, Feb 5, 2011 at 7:36 PM, Bart Van Assche bvanass...@acm.orgwrote: On Sat, Feb 5, 2011 at 2:22 PM, Konstantin Serebryany konstantin.s.serebry...@gmail.com wrote: FYI ThreadSanitizer will not report anything on this test, even with --free-is-write (which is on by default) because this tool assumes the malloc implementation to be correct and ignores every access inside malloc and friends. I haven't seen any false positives due to --free-is-write (in ThreadSanitizer) over last ~6 months, but we found tons of real races with this flag. Just a fresh example: http://code.google.com/p/chromium/issues/detail?id=72042 Hello Konstantin, Has that --free-is-write feature already been tested in combination with custom memory allocators ? What kind of custom memory allocators? We regularly run it with programs linked against tcmalloc. Hello Konstantin, With custom memory allocators I was referring to those using the VG_USERREQ__MALLOCLIKE_BLOCK and VG_USERREQ__FREELIKE_BLOCK client requests and not to those that replace malloc() like e.g. tcmalloc. ThreadSanitizer does not support VG_USERREQ__FREELIKE_BLOCK -- never found a use for it yet. However if a program uses a lot of custom free lists it could be useful (and it will be trivial to implement). Hello Konstantin, Sure, I don't doubt that implementing support for VG_USERREQ__FREELIKE_BLOCK in TS would be trivial to implement. What might be hard to implement regarding --free-is-write is to ignore the memory accesses inside the custom allocator. This is because such a custom allocator issues VG_USERREQ__MALLOCLIKE_BLOCK after it has finished updating its internal data structures and because the tool is not informed when the custom memory allocator in the client starts updating its internal data structures. Bart. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] DRD and --free-is-write bug-report
On Sat, Feb 5, 2011 at 5:54 PM, Konstantin Serebryany konstantin.s.serebry...@gmail.com wrote: On Sat, Feb 5, 2011 at 7:36 PM, Bart Van Assche bvanass...@acm.orgwrote: On Sat, Feb 5, 2011 at 2:22 PM, Konstantin Serebryany konstantin.s.serebry...@gmail.com wrote: FYI ThreadSanitizer will not report anything on this test, even with --free-is-write (which is on by default) because this tool assumes the malloc implementation to be correct and ignores every access inside malloc and friends. I haven't seen any false positives due to --free-is-write (in ThreadSanitizer) over last ~6 months, but we found tons of real races with this flag. Just a fresh example: http://code.google.com/p/chromium/issues/detail?id=72042 Hello Konstantin, Has that --free-is-write feature already been tested in combination with custom memory allocators ? What kind of custom memory allocators? We regularly run it with programs linked against tcmalloc. Hello Konstantin, With custom memory allocators I was referring to those using the VG_USERREQ__MALLOCLIKE_BLOCK and VG_USERREQ__FREELIKE_BLOCK client requests and not to those that replace malloc() like e.g. tcmalloc. Bart. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] DRD and --free-is-write bug-report
On Sat, Feb 5, 2011 at 2:22 PM, Konstantin Serebryany konstantin.s.serebry...@gmail.com wrote: FYI ThreadSanitizer will not report anything on this test, even with --free-is-write (which is on by default) because this tool assumes the malloc implementation to be correct and ignores every access inside malloc and friends. I haven't seen any false positives due to --free-is-write (in ThreadSanitizer) over last ~6 months, but we found tons of real races with this flag. Just a fresh example: http://code.google.com/p/chromium/issues/detail?id=72042 Hello Konstantin, Has that --free-is-write feature already been tested in combination with custom memory allocators ? Bart. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] DRD and --free-is-write bug-report
On Fri, Feb 4, 2011 at 12:16 PM, Andrea Mazzoleni amadva...@gmail.com wrote: I likely found a problem in the DRD when using the --free-is-write option. The following test case reports an huge amount of errors that are not expected. Valgrind and helgrind report no error. The machine is a Ubuntu 10.4 x86 with valgrind 3.6.0 compiled from source. The program is compiled with: gcc -O1 -g -D_REENTRANT multi.c -o multi -lpthread In a big application I have similar strange reports, even without using --free-is-write, so maybe --free-is-write is only a way to expose the bug. The implementation of --free-is-write in DRD is based on the assumption that all modifications of memory after a call to free() and before a new malloc() call returns it again are errors. I'm afraid this assumption is wrong (the memory allocator may touch such memory) so I have removed the --free-is-write option again. Regarding the behavior of DRD with --free-is-write=no: DRD in this configuration is working reliably for many people since considerable time. So the issues reported with this configuration are most likely either application errors or false positives triggered by the distro-specific libthread or libc implementation. One should keep in mind that the data race detection algorithms in DRD and Helgrind are different and hence that both tools may report different data races or false positives. Further feedback for the behavior of DRD with --free-is-write=no is welcome. Bart. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] [exim-dev] [Bug 1050] [PATCH] Portability fixes for memcheck.h.
On Wed, Jan 12, 2011 at 8:53 AM, David Woodhouse dw...@infradead.org wrote:
On Tue, 2011-01-11 at 15:12 +, Tony Finch wrote:
Exim doesn't compile with Sun or HP CC since Valgrind support was
added. Although valgrind.h protects against usage on unsupported
platforms, memcheck.h uses the __extension__() macro without checking.
Remove all uses since VALGRIND_DO_CLIENT_REQUEST() has all the
necessary portability support.
---
Chris and Steen,
Could you please try this patch and see if it fixes the
compilation problems with 4.73?
Thanks.
This wants to go to Valgrind upstream too.
[ ... ]
/* Client-code macros to check the state of memory. */
@@ -176,24 +176,24 @@ typedef
error message and returns the address of the first offending byte.
Otherwise it returns zero. */
#define VALGRIND_CHECK_MEM_IS_ADDRESSABLE(_qzz_addr,_qzz_len) \
- (__extension__({unsigned long _qzz_res; \
+ {unsigned long _qzz_res; \
VALGRIND_DO_CLIENT_REQUEST(_qzz_res, 0, \
VG_USERREQ__CHECK_MEM_IS_ADDRESSABLE,\
_qzz_addr, _qzz_len, 0, 0, 0); \
_qzz_res; \
- }))
+ }
[ ... ]
Hello Tony,
Did you realize that with that patch you have broken
VALGRIND_CHECK_MEM_IS_ADDRESSABLE() and several other macros ? The
above patch converts e.g. the following code into a syntax error:
void* addr;
int len;
int addressable;
addressable = VALGRIND_CHECK_MEM_IS_ADDRESSABLE(addr, len);
Bart.
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] [exim-dev] [Bug 1050] [PATCH] Portability fixes for memcheck.h.
On Wed, Jan 12, 2011 at 3:28 PM, Tony Finch d...@dotat.at wrote:
On Wed, 12 Jan 2011, David Woodhouse wrote:
Can we turn the ({ ... }) extension into a static inline function? Or is
that not sufficiently portable either?
No, nested functions are not allowed in standard C.
It looks to me like the macros were originally written so that the first
argument was supposed to be an lvalue to receive the result, and they were
not supposed to be used in an expression context. To make the
block-expression wrappers work, I think the basic
VALGRIND_DO_CLIENT_REQUEST() macro will have to be changed to return a
result rather than take an lvalue.
Please have a look at vg_VALGRIND_DO_CLIENT_REQUEST_EXPR() in
valgrind/valgrind.h (as included in version 3.6.0).
Bart.
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind test suite on different target.
On Wed, Sep 15, 2010 at 9:58 AM, Alessandro Biasci a.bia...@evidence.eu.com wrote: On 14/09/2010 16:59, John Reiser wrote: $ make CROSS_COMPILE=powerpc-860-linux-gnu CC=powerpc-860-linux-gnu-gcc regtest Now I'd like to execute this tests on the target platform (that isn't the same of compile) and not after the compile step [which was performed on the build platform.] On the target platform, make it look as if you had just completed a native build, then run make regtest. To do this, go to the build platform, create a 'tar' archive of the build tree, go to the target platform, extract the 'tar' archive so that all files have the same rooted pathnames as on the build platform. Then install (perhaps by make install) and finally make regtest. Thanks it's a great idea. But I have always a problem after the copy of files in target board. Typing make regtest it want to rebuild some files. I don't have a native compiler for the target board but only a cross-compiler. So I need that make regtest doesn't rebuild any files but only executes the tests. Have you already tried to run the command perl tests/vg_regtest ? Bart. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] valgrind and boost::thread
On Thu, Sep 2, 2010 at 5:13 PM, cqu...@arcor.de wrote: Hi! I am using valgrind together with boost::thread_pool and memcheck reports a memory leak. In the boost mailing list it seems that it is not a problem with boost: http://lists.boost.org/Archives/boost/2010/08/170274.php Is that something that can be fixed in valgrind so that this is not reported as a memory leak? My opinion is that Valgrind correctly reports a memory leak. See also https://bugzilla.redhat.com/show_bug.cgi?id=629673 if you want to know what the cause of this issue is (the Boost people got it wrong). Bart. -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] WARNING: Serious error when reading debug info in valgrind 3.5
On Thu, Aug 26, 2010 at 2:34 PM, Sorin Dumitru sdumi...@ixiacom.com wrote: I am running into a little problem using valgrind 3.5 on powerpc. When I start valgrind with --leak-check=full I get some warnings at the start: --247-- WARNING: Serious error when reading debug info --247-- When reading debug info from /shared/chassis/arch/lib/valgrind/vgpreload_core-ppc32-linux.so: --247-- Can't make sense of .sdata section mapping [ ... ] This does not happen when I use version 3.3. Did anything change between those two versions that might explain this? The full output from valgrind can be found here: http://pastebin.com/YwPQV0wA Some PPC compilers generate debug info by default in the stabs format. It's possible that something has changed in Valgrind with regard to reading stabs debug info between version 3.3 and 3.5. The quickest way to get useful output from Valgrind 3.5.0 or later on PowerPC is to build Valgrind and the applications that you want to analyze with DWARF debug information (gcc command-line option -gdwarf-2; specify CFLAGS=-gdwarf-2 when configuring Valgrind). Bart. -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Stack size of a program
On Tue, Aug 24, 2010 at 12:30 AM, Juan Carlos Martinez Santos juanc.martinez.san...@gmail.com wrote: Is there a way to figure out how much the stack grows during the execution using Valgrind? This is possible with DRD and --show-stack-usage -- see also http://www.valgrind.org/docs/manual/drd-manual.html#drd-manual.options. Bart. -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Invalid read
On Mon, Jul 26, 2010 at 9:13 AM, Sato Takenori takenori.s...@gmail.comwrote:
I get the following Invalid read error on the part below.
103if(counter_-decrement() == 0){
104delete counter_;
105if(pointee_) delete pointee_;
106}
107counter_ = src-counter_;
108pointee_ = src-pointee_;
==3581== Invalid read of size 8
==3581==at 0x401625: DefaultStoragePSPIntSLLNode,
MutexCounter::replace(DefaultStoragePSPIntSLLNode, MutexCounter*)
(PSP.h:107)
==3581==by 0x401410: PSPPSPIntSLLNode, MutexCounter,
DefaultStorage::operator=(PSPPSPIntSLLNode, MutexCounter,
DefaultStorage) (PSP.h:276)
==3581==by 0x400C49: PSPIntSLList::~PSPIntSLList()
(PSPIntSLList.cpp:11)
==3581==by 0x4010FF: main (PSPIntSLList.cpp:59)
==3581== Address 0x4c24150 is 48 bytes inside a block of size 56 free'd
==3581==at 0x4A05A76: operator delete(void*) (vg_replace_malloc.c:387)
==3581==by 0x401620: DefaultStoragePSPIntSLLNode,
MutexCounter::replace(DefaultStoragePSPIntSLLNode, MutexCounter*)
(PSP.h:105)
==3581==by 0x401410: PSPPSPIntSLLNode, MutexCounter,
DefaultStorage::operator=(PSPPSPIntSLLNode, MutexCounter,
DefaultStorage) (PSP.h:276)
==3581==by 0x400C49: PSPIntSLList::~PSPIntSLList()
(PSPIntSLList.cpp:11)
==3581==by 0x4010FF: main (PSPIntSLList.cpp:59)
==3581==
==3581== Invalid read of size 8
==3581==at 0x401635: DefaultStoragePSPIntSLLNode,
MutexCounter::replace(DefaultStoragePSPIntSLLNode, MutexCounter*)
(PSP.h:108)
==3581==by 0x401410: PSPPSPIntSLLNode, MutexCounter,
DefaultStorage::operator=(PSPPSPIntSLLNode, MutexCounter,
DefaultStorage) (PSP.h:276)
==3581==by 0x400C49: PSPIntSLList::~PSPIntSLList()
(PSPIntSLList.cpp:11)
==3581==by 0x4010FF: main (PSPIntSLList.cpp:59)
==3581== Address 0x4c24148 is 40 bytes inside a block of size 56 free'd
==3581==at 0x4A05A76: operator delete(void*) (vg_replace_malloc.c:387)
==3581==by 0x401620: DefaultStoragePSPIntSLLNode,
MutexCounter::replace(DefaultStoragePSPIntSLLNode, MutexCounter*)
(PSP.h:105)
==3581==by 0x401410: PSPPSPIntSLLNode, MutexCounter,
DefaultStorage::operator=(PSPPSPIntSLLNode, MutexCounter,
DefaultStorage) (PSP.h:276)
==3581==by 0x400C49: PSPIntSLList::~PSPIntSLList()
(PSPIntSLList.cpp:11)
==3581==by 0x4010FF: main (PSPIntSLList.cpp:59)
Both of pointee_ and counter_ are member fields of the class.
This error means pointee_ and counter_ are asigned at line 107 and 108
after deletions at line 105(104), correct?
This probably means that src is or became a dangling pointer. Have you
verified that *this and *src are different objects before freeing
this-counter_ and this-pointee_ ?
Bart.
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] C++ function wrapping: wrong mangled names
On Tue, Jul 20, 2010 at 5:43 PM, Patrick Heckeler hecke...@informatik.uni-tuebingen.de wrote: On 20 July 2010 17:13, Dan Kegel d...@kegel.com wrote: On Tue, Jul 20, 2010 at 7:33 AM, Patrick Heckeler hecke...@informatik.uni-tuebingen.de wrote: Is there any other possibility to wrap C++ functions? Well, you could use extern C on that one function to disable the mangling, but you already knew that. (And it won't work if you have several functions with the same name but different signatures.) - Dan I have tested extern Cand it works. But I want to use the wrapping later on for C++ methods. And extern C cannot handle class methods :-) It can, at least if you specify the mangled name. There are several examples in drd/drd_qtcore_intercepts.c. Bart. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] drd with process-shared mutexes
On Sun, Jun 20, 2010 at 9:30 PM, Howard Chu h...@symas.com wrote: Howard Chu wrote: The BerkeleyDB library uses blocks of persistent shared memory to store its environment state, which includes arrays of interprocess shared mutexes. Running an app that uses BDB under valgrind/drd gives a ton of The object at address 0xXXX is not a mutex. apparently because drd didn't see the mutex_init call. (And it won't see it, because the environment and those mutexes were initialized by some process other than the one being tested.) Is there a way to tell DRD that these mutexes are actually valid, and stop complaining about them? I changed my test so that the environment initialization occurs in the same process as the main test, but valgrind 3.4.1 still gave a bunch of not a mutex errors. Upgrading to 3.5.0 seems to have fixed that though, so this seems to be a solved problem. You need indeed Valgrind 3.5.0 for proper support of process-shared mutexes in DRD. More details about the 3.5.0 release can be found in the Valgrind release notes (http://valgrind.org/docs/manual/dist.news.html). Note: if you are using Boost, it's better to use the trunk instead of version 3.5.0. Bart. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Cross compiling valgrind 3.5.0 for ppc
On Mon, Jun 14, 2010 at 5:28 PM, Robert Berger robert.karl.ber...@gmail.com wrote: It looks like last time this mail did not make it to the list. Here I try again. Hi Robert, Does the current Valgrind trunk build and install fine on your setup ? Cross-compilation should work again with the current trunk. Bart. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Cross compiling valgrind 3.5.0 for ppc
On Tue, Jun 15, 2010 at 5:55 PM, Robert Berger robert.karl.ber...@gmail.com wrote: [ ... ] That's what my target says: -bash-3.2# valgrind valgrind: failed to start tool 'memcheck' for platform 'ppc32-linux': No such file or directory -bash-3.2# You can analyze what went wrong by analyzing the output of the following command: valgrind -v -d /bin/date Bart. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Running Valgrind on ELF/ python/ boost based executables
On Sun, Jun 13, 2010 at 11:47 AM, Satya V. Gupta guptasa...@netzero.net wrote: I have a supervisory process that is kicked off by an ELF executable which in turn invokes some ELF/ python script/ executables based child processes. I wish to run valgrind with --tool=callgrind and be able to inject valgrind into all processes. So far I have tried to run the supervisory process with --trace-children=yes and of course --tool=callgrind switches. Any ELF based executable process stays up but valgrind receives a SIGSEGV from all the others. It leaves behind an identical call stack strace with a bunch of exception handlers that pass through the main python executable and a bunch of boost libraries. Does anyone have recommendations on how to run python/ boost based executable? Instead of asking the same question twice, you should try the suggestion that was posted in reply to your message on the valgrind-developers mailing list (see also http://sourceforge.net/mailarchive/forum.php?thread_name=201006122144.03178.jseward%40acm.orgforum_name=valgrind-developers). Bart. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Cross compiling valgrind 3.5.0 for ppc
On Sun, Jun 13, 2010 at 1:51 PM, Robert Berger gm...@reliableembeddedsystems.com wrote: On 06/10/2010 07:38 PM, Bart Van Assche wrote: I'm using ELDK 4.2 on an AMCC kilauea board: All on the host: svn co svn://svn.valgrind.org/valgrind/branches/VALGRIND_3_5_BRANCH VALGRIND_PATH=VALGRIND_3_5_BRANCH The patches are attached as well. This patch is to remove the altivec instructions patch -p1 patches/altivec.diff This patch is to make the linker happy. In function `__divsf3': /opt/eldk/build/ppc-2008-04-01/work/usr/src/denx/BUILD/crosstool-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/gcc-4.2.2/gcc/config/soft-fp/divsf3.c:44: undefined reference to `abort' patch -p1 patches/abort.diff cd $VALGRIND_PATH source ../../../env.sh make distclean echo autogen ./autogen.sh --host=powerpc-linux --target=powerpc-linux --disable-tls --prefix=$ELDK_PREFIX/eldk-4.2-ppc_4xx/ppc_4xx echo configure ./configure --host=powerpc-linux --target=powerpc-linux --disable-tls --prefix=$ELDK_PREFIX/eldk-4.2-ppc_4xx/ppc_4xx echo make make So far so bad. With make install on the host we fail here: win.h' '/work/rber/eldk-4.2-ppc_4xx/ppc_4xx/include/valgrind/vki/vki-scnums-darwin.h' make[3]: Leaving directory `/home/rber/projects/ldd/ldd_for_trainer/src/31_valgrind/VALGRIND_3_5_BRANCH/include' make[2]: Leaving directory `/home/rber/projects/ldd/ldd_for_trainer/src/31_valgrind/VALGRIND_3_5_BRANCH/include' Making install in VEX make[2]: Entering directory `/home/rber/projects/ldd/ldd_for_trainer/src/31_valgrind/VALGRIND_3_5_BRANCH/VEX' make install-am make[3]: Entering directory `/home/rber/projects/ldd/ldd_for_trainer/src/31_valgrind/VALGRIND_3_5_BRANCH/VEX' make[4]: Entering directory `/home/rber/projects/ldd/ldd_for_trainer/src/31_valgrind/VALGRIND_3_5_BRANCH/VEX' test -z /work/rber/eldk-4.2-ppc_4xx/ppc_4xx/lib/valgrind || /bin/mkdir -p /work/rber/eldk-4.2-ppc_4xx/ppc_4xx/lib/valgrind /usr/bin/install -c -m 644 'libvex-ppc32-linux.a' '/work/rber/eldk-4.2-ppc_4xx/ppc_4xx/lib/valgrind/libvex-ppc32-linux.a' powerpc-linux-ranlib '/work/rber/eldk-4.2-ppc_4xx/ppc_4xx/lib/valgrind/libvex-ppc32-linux.a' /bin/sh: line 4: powerpc-linux-ranlib: command not found Which is strange, since powerpc-linux-ranlib is definitely on the patch. The first and second issue should now be fixed on the trunk (r11172 and r11173 respectively). Not sure why powerpc-linux-ranlib could not be found - I have never seen this before. Maybe this is a local issue ? Note: cross-compilation will work soon again on the trunk - a patch has already been posted by Julian on the valgrind-developers mailinglist. Bart. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Can data from checkgrind output files be directed to a network socket instead
On Tue, Jun 8, 2010 at 11:25 AM, Satya V. Gupta guptasa...@netzero.netwrote: I am using checkgrind on a system that has very little disk space. I am wondering if someone knows how I can direct the checkgrind output files (basic block, Function before, Function after) to a network socket instead? The most convenient way to make sure that data is saved somewhere else is to use NFS. Just mount a directory via NFS from a server (e.g. on /mnt), change the current directory to /mnt and start checkgrind (what is checkgrind ?). Bart. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] [drd] Race condition in example/http/server2 from boost asio library?
On Tue, Jun 8, 2010 at 4:25 AM, Jorge Moraleda jorge.moral...@gmail.com wrote: I compile example/http/server2 from boost (1.43) asio library using: g++ -l boost_thread -l boost_system /opt/boost/boost/doc/html/boost_asio/example/http/server2/*cpp When I run it using valgrind drd (svn r11158) using: valgrind --tool=drd ./a.out 127.0.0.1 31175 4 /tmp The output is clean until the first time I connect to the server (by typing http://localhost:31175/anything on a browser) at which point several warnings pop up as shown below. Are these false alarms, or actual concurrency bugs in boost asio or the example code? Thank you, Jorge ==15768== drd, a thread error detector ==15768== Copyright (C) 2006-2010, and GNU GPL'd, by Bart Van Assche. ==15768== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info ==15768== Command: ./a.out 127.0.0.1 31175 8 /tmp ==15768== ==15768== Thread 4: ==15768== Conflicting load by thread 4 at 0x061875f0 size 8 ==15768== at 0x40DB72: boost::asio::detail::op_queueboost::asio::detail::reactor_op::front() (in /tmp/a.out) ==15768== by 0x417974: boost::asio::detail::epoll_reactor::run(bool, boost::asio::detail::op_queueboost::asio::detail::task_io_service_operationboost::asio::detail::epoll_reactor ) (in /tmp/a.out) [ ... ] This looks like a race on descriptor_state::op_queue_, so I had a look at the following source code: http://www.boost.org/doc/libs/1_43_0/boost/asio/detail/epoll_reactor.hpp. My comments on this source code are as follows: * The comments at the bottom of class epoll_reactor say that any access of registered_descriptors_ should be protected by registered_descriptors_mutex_. However, the method shutdown_service() modifies the container registered_descriptors_ but doesn't lock registered_descriptors_mutex_. * The method epoll_reactor::register_descriptor() modifies its second argument (descriptor_data) such that it points to the newly created descriptor_state object. All data members of the struct descriptor_state are public, but all accesses must be guarded by a lock on descriptor_state::mutex_. So all callers of register_descriptor() must be checked in order to verify whether or not there are any thread-unsafe accesses of descriptor_state::op_queue_ or descriptor_state::shutdown_. Personally I never recommended such a class design. * While all accesses of the members of struct descriptor_state should be protected by locking descriptor_state::mutex_, no lock is held on this last mutex by register_descriptor() when it sets descriptor_data::shutdown_ nor by shutdown_service() while it modifies descriptor_state::op_queue_ and descriptor_state::shutdown_. The former is easy to fix: move the descriptor_data-shutdown_ = false statement to somewhere before the epoll_ctl() system call. Does one of the above scenarios explain the race report you have observed ? Bart. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] [drd] Race condition in boost thread library?
On Tue, Jun 8, 2010 at 4:06 AM, Jorge Moraleda jorge.moral...@gmail.com wrote: [ ... ] I recompiled boost from source using: bjam variant=debug define=BOOST_LOG_USE_CHAR install and all the above warnings are gone. When I run the program, half of the time I get a clean output, the other 10% of the time I get the following: ==14837== drd, a thread error detector ==14837== Copyright (C) 2006-2010, and GNU GPL'd, by Bart Van Assche. ==14837== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info ==14837== Command: ./a.out ==14837== ==14837== Thread 3: ==14837== Conflicting load by thread 3 at 0x05d8a288 size 8 ==14837== at 0x5B78ECE: __nptl_deallocate_tsd (pthread_create.c:153) [ ... ] I had a look at the implementation in glibc of the function __nptl_deallocate_tsd(). The function itself looks fine. So this kind of race report is probably caused by reuse of the memory for thread-local storage from a terminated thread by a newly created thread. I have added a suppression pattern for the above report. Bart. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] link_tool_exe: cannot execute binary file
On Sun, Jun 6, 2010 at 10:41 PM, Julian Seward jsew...@acm.org wrote: Oh, darn. It looks like I broke cross compilation recently by introducing link_tool_exe.c as part of the build process. Honestly .. the your best bet is to rewrite link_tool_exe.c as a perl script, so it can run on the host. I actually started out to write it as a perl script, but couldn't find a way to make it portably do 64-bit arithmetic, which it needs to do on some platforms. Hence I wimped out and wrote a C program instead. However, that evidently isn't going to work in this case. Why Perl ? Perl isn't used anywhere yet during the Valgrind build -- that would introduce an additional dependency. Bash can do 64-bit arithmetic as well. An example: $ bash -c 'echo $((162))' 4611686018427387904 Bart. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] [drd] Race condition in boost thread library?
On Sat, Jun 5, 2010 at 2:52 AM, Jorge Moraleda jorge.moral...@gmail.com wrote: I got a drd error in one of my programs, and searching on the web I found the following boost bug report, including a test sample reporting the same error found with drd. https://svn.boost.org/trac/boost/ticket/3526 with a similar error. There they seem to conclude that this is not a real problem, but I wanted to get your opinion. I can reproduce the error. I am running boost 1.43 and valgrind 11150M (with Bart's linker fix, thank you!!!). You are welcome to test Valgrind r11146 or later (unmodified) -- Julian has fixed the mmap(...) failed in UME with error 22 (Invalid argument) error message. This is the test code they provide in the link above. [ ... ] This is my valgrind output when compiled with g++ -l boost_thread main.cpp valgrind --tool=drd ./a.out ==7014== drd, a thread error detector ==7014== Copyright (C) 2006-2010, and GNU GPL'd, by Bart Van Assche. ==7014== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info ==7014== Command: ./a.out ==7014== ==7014== Thread 3: ==7014== Conflicting store by thread 3 at 0x0504c750 size 8 ==7014== at 0x4E41A23: T.1292 (in /usr/local/lib/libboost_thread.so.1.43.0) [ ... ] Looks like a false positive on current_thread_tls_key to me, so I have added a suppression pattern in r11152. Bart. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] [drd] False 'condition variable not initialized' in boost library?
On Wed, Jun 2, 2010 at 10:04 PM, Jorge Moraleda jorge.moral...@gmail.com wrote: [ ... ] Thank you. I just tried r11145. It stops both with drd and memcheck, even in very small programs, after giving the following output: valgrind: mmap(0x40, 823296) failed in UME with error 22 (Invalid argument). valgrind: this can be caused by executables with very large text, data or bss segments. You can use the following as a temporary workaround for the mmap() error message: cd valgrind svn merge r11141:11140 . svn revert coregrind/link_tool_exe.c Bart. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] [drd] race condition in std::istringstream / std::getline
On Thu, May 27, 2010 at 4:29 AM, Jorge Moraleda
jorge.moral...@gmail.com wrote:
Dear all,
Am I doing something wrong, or is is there a race condition somewhere
in std::istringstream and/or std::getline?
(Bart, Konstantin, this ended up being the error that I've been trying
to track down for a while and that I thought --erroneously-- was
caused by std::locale)
This program:
/// file: thread.cpp
#include pthread.h
#include string
#include sstream
void *threadEntry(void *threadid)
{
std::string bar(01\n23);
std::istringstream content(bar);
std::string line;
std::getline(content,line);
pthread_exit(NULL);
}
int main (int argc, char *argv[])
{
pthread_t threads[2];
int rc;
long t;
std::ostringstream dummy;
dummy 0;
for(t=0; t2; t++) {
rc = pthread_create(threads[t], NULL, threadEntry, (void *)t);
}
pthread_exit(NULL);
}
when compiled using g++ -g -pthread thread.cpp
and run with valgrind --tool=drd ./a.out
produces the following output:
==10635== drd, a thread error detector
==10635== Copyright (C) 2006-2009, and GNU GPL'd, by Bart Van Assche.
==10635== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for
copyright info
==10635== Command: ./a.out
==10635==
==10635== Thread 3:
==10635== Conflicting load by thread 3 at 0x05134160 size 8
==10635== at 0x4EBBC2A: std::basic_istreamchar,
std::char_traitschar std::getlinechar, std::char_traitschar,
std::allocatorchar (std::basic_istreamchar, std::char_traitschar
, std::basic_stringchar, std::char_traitschar,
std::allocatorchar , char) (in /usr/lib/libstdc++.so.6.0.13)
==10635== by 0x400D03: threadEntry(void*) (threads2.cpp:12)
==10635== by 0x4C32870: vgDrd_thread_wrapper (drd_pthread_intercepts.c:272)
==10635== by 0x55E8A03: start_thread (pthread_create.c:300)
==10635== by 0x58DD80C: clone (clone.S:112)
[ ... ]
Strange. I have tried to reproduce this with gcc 4.4.4 (which includes
libstdc++.so.6.0.13), but did not see any race reports.
Does inserting two pthread_join() calls between pthread_create() and
pthread_exit() in main() help ?
Bart.
--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] [Valgrind-developers] Valgrind cross compilation error for PPC32_LINUX
On Wed, May 26, 2010 at 9:04 PM, Gary Yang garyya...@yahoo.com wrote: [ ... ] m_dispatch/dispatch-ppc32-linux.S:142: Error: Unrecognized opcode: `stvx' [ ... ] See also https://bugs.kde.org/show_bug.cgi?id=238745. Bart. -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] [Valgrind-developers] How to get the 3.5 branch code?
On Wed, May 26, 2010 at 9:05 PM, Gary Yang garyya...@yahoo.com wrote: I used the command, svn co svn://svn.valgrind.org/valgrind/trunk valgrind got the trunk code. I would like to get the 3.5 branch code. Can someone tell me how? Have you already tried the command below ? svn ls svn://svn.valgrind.org/valgrind/branches Bart. -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Conflicting load reported on libstdc++ std::string
On Tue, May 11, 2010 at 4:31 PM, Konstantin Serebryany konstantin.s.serebry...@gmail.com wrote: On Tue, May 11, 2010 at 6:27 PM, Bart Van Assche bvanass...@acm.orgwrote: On Tue, May 11, 2010 at 11:20 AM, Konstantin Serebryany konstantin.s.serebry...@gmail.com wrote: Have you already found a workaround that allows to avoid triggering the race report on std::locale::locale() ? If not, it would help if you could post a small example that allows to reproduce this behavior. You may like the test NegativeTests.EmptyRepTest from http://code.google.com/p/data-race-test/wiki/RacecheckUnittest % ~/valgrind/trunk/inst/bin/valgrind --tool=helgrind ./bin/racecheck_unittest-linux-x86-O0 --gtest_filter=NegativeTests.EmptyRepTest ==28925== Possible data race during read of size 4 at 0x7fbf5b8 by thread #3 ==28925==at 0x7F6F3A2: std::string::erase(unsigned int, unsigned int) (in /usr/grte/v1/lib/libstdc++.so.6.0.9) ==28925==by 0x804CB82: NegativeTests_EmptyRep::Worker() (racecheck_unittest.cc:3168) ==28925==by 0x806E806: MyThread::ThreadBody(MyThread*) (thread_wrappers_pthread.h:329) ==28925==by 0x47C4155: mythread_wrapper (hg_intercepts.c:213) ==28925==by 0x47F1024: start_thread (in /usr/grte/v1/lib/ libpthread-2.3.6.so) ==28925==by 0x1BD4A75D: clone (in /usr/grte/v1/lib/libc-2.3.6.so) ==28925== This conflicts with a previous write of size 4 by thread #2 ==28925==at 0x7F6EC1B: std::string::_M_mutate(unsigned int, unsigned int, unsigned int) (in /usr/grte/v1/lib/libstdc++.so.6.0.9) ==28925==by 0x7F6F3C6: std::string::erase(unsigned int, unsigned int) (in /usr/grte/v1/lib/libstdc++.so.6.0.9) ==28925==by 0x804CB82: NegativeTests_EmptyRep::Worker() (racecheck_unittest.cc:3168) ==28925==by 0x806E806: MyThread::ThreadBody(MyThread*) (thread_wrappers_pthread.h:329) ==28925==by 0x47C4155: mythread_wrapper (hg_intercepts.c:213) ==28925==by 0x47F1024: start_thread (in /usr/grte/v1/lib/ libpthread-2.3.6.so) ==28925==by 0x1BD4A75D: clone (in /usr/grte/v1/lib/libc-2.3.6.so) % ~/valgrind/trunk/inst/bin/valgrind --tool=drd ./bin/racecheck_unittest-linux-x86-O0 --gtest_filter=NegativeTests.EmptyRepTest ==28930== ==28930== Conflicting load by thread 3 at 0x04b1f5b8 size 4 ==28930==at 0x4ACEB7E: std::string::_M_mutate(unsigned int, unsigned int, unsigned int) (in /usr/grte/v1/lib/libstdc++.so.6.0.9) ==28930==by 0x4ACF3C6: std::string::erase(unsigned int, unsigned int) (in /usr/grte/v1/lib/libstdc++.so.6.0.9) ==28930==by 0x804CB82: NegativeTests_EmptyRep::Worker() (racecheck_unittest.cc:3168) ==28930==by 0x806E806: MyThread::ThreadBody(MyThread*) (thread_wrappers_pthread.h:329) ==28930==by 0x47C9BBD: vgDrd_thread_wrapper (drd_pthread_intercepts.c:272) ==28930==by 0x47F7024: start_thread (in /usr/grte/v1/lib/ libpthread-2.3.6.so) ==28930==by 0x4BED75D: clone (in /usr/grte/v1/lib/libc-2.3.6.so) ==28930== Allocation context: BSS section of /usr/grte/v1/lib/libstdc++.so.6.0.9 ==28930== Other segment start (thread 2) ==28930==(thread finished, call stack no longer available) ==28930== Other segment end (thread 2) ==28930==(thread finished, call stack no longer available) ==28930== Why did you post this in reply to a message about std::locale::locale() ? As far as I can see the race reported on the std::string object and the race reported on std::locale::locale() are unrelated. Oops, my fault... Indeed, a reproducer for a std::locale::locale() would be nice. I haven't seen it so far... No problem. Regarding the race on the std::string refcount: this race is a really annoying one. According to the information in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518 this issue has been fixed in both gcc 4.4.4 and gcc 4.5.0. The output I get with Valgrind r11128 (trunk) and gcc 4.4.4 (which included libstdc++ version 6.0.13) confirms this: $ export LD_LIBRARY_PATH=/home/bart/gcc-4.4.4/lib64:/home/bart/gmp-5.0.1/lib:/home/bart/mpfr-2.4.2/lib:/home/bart/mpc-0.8.1/lib: $ ~/software/valgrind/vg-in-place --tool=drd --gen-suppressions=all bin/racecheck_unittest-linux-amd64-O0 --gtest_filter=NegativeTests.EmptyRepTest ==28564== drd, a thread error detector ==28564== Copyright (C) 2006-2010, and GNU GPL'd, by Bart Van Assche. ==28564== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info ==28564== Command: bin/racecheck_unittest-linux-amd64-O0 --gtest_filter=NegativeTests.EmptyRepTest ==28564== Not running under ThreadSanitizer (query=hybrid_fast) Not running under ThreadSanitizer (query=pure_happens_before) FLAGS [phb=0, fm=0] No tests specified. Running default set of tests... Note: Google Test filter = NegativeTests.EmptyRepTest [==] Running 1 test from 1 test case. [--] Global test environment set-up. [--] 1 test from NegativeTests [ RUN ] NegativeTests.EmptyRepTest [ OK ] NegativeTests.EmptyRepTest (42 ms) [--] 1 test from
Re: [Valgrind-users] novice drd user. Errors in std streams
On Wed, Apr 21, 2010 at 3:40 AM, Jorge Moraleda jorge.moral...@gmail.com wrote: Hello Jorge, Unfortunately not all libraries have been designed with data-race detection tools in mind. Several libraries contain code that triggers benign data races. Examples are the I/O code in libstdc++ and in libc. You can either create a suppression pattern to suppress the above races, or even simpler, add the following code in main() before thread creation starts: std::ostringstream dummy; dummy 0; The above code will make sure that locale initialization, which is triggered by sending an number to an I/O stream, will happen before any threads are created and hence no races will be reported anymore on locale initialization. This will not hide the race on _ZNSs4_Rep20_S_empty_rep_storageE. And suppressing errors in string guts may hide real races. Bart. Hello Konstanting and Bart and others, I get race condition warnings ==20312== at 0x4C29303: pthread_mutex_lock (drd_pthread_intercepts.c:580) ==20312== by 0x6EAC85E: std::locale::locale() (in /usr/lib/libstdc++.so.6.0.13) ==20312== by 0x6EE0C93: std::basic_stringstreamchar, std::char_traitschar, std::allocatorchar ::basic_stringstream(std::_Ios_Openmode) (in /usr/lib/libstdc++.so.6.0.13) when constructing std::stringstream and std::istringstream's. These look similar to the ones I asked about for std::ostringstream a few weeks ago. I tried a similar trick to the one Konstantin suggested for ostringstream. Namely, to write the following lines before thread creation starts: std::stringstream dummy2; dummy2 0; std::istringstream dummy3(dummy2.str()); But I still get warnings. Is there any initialization trick that works? Has a bug report been already filed against the stl? That is, assuming these are real bugs, I have not been able to find any information about locale race conditions on the web. If they are not real bugs, but false positives, are there any magic drd macros, like the one Konstantin described for the string::clear method extern char _ZNSs4_Rep20_S_empty_rep_storageE[32]; DRD_IGNORE_VAR(_ZNSs4_Rep20_S_empty_rep_storageE); that I can include to not report these errors? By the way, I also get these race condition warnings for locale initialization when using boost::lexical_cast. Have you already found a workaround that allows to avoid triggering the race report on std::locale::locale() ? If not, it would help if you could post a small example that allows to reproduce this behavior. Bart. -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] massif segmentation fault
On Thu, May 6, 2010 at 10:06 PM, Jorge Moraleda jorge.moral...@gmail.comwrote: I have a program that makes massif crash reproducibly with a segmentation fault. This occurs in the release version 3.5.0 as well as in one compiled from source today from subversion: valgrind-3.6.0.SVN. The program runs fine in massif 3.3.1 compiled from source. This crash occurs reproducibly in debian sid up to date and OpenSUSE, both amd-64 bit architectures. The program is too large to send away, and I have not been able to make a small test case that reproduces the bug, but I am happy to spend sometime helping to fix this if anyone can tell me what other information I can provide. Have you already verified whether your program is memcheck-clean ? And if your program is multithreaded, have you already verified whether it is data-race-free ? Bart. -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Identify variable in DRD -- or do I need a suppression?
On Wed, Apr 14, 2010 at 8:34 AM, Rainer Gerhards rgerha...@gmail.comwrote: I am working with the svn version of valgrind (updated this morning). I see a series of violations in drd which I can not identify the root cause. An example violation looks like this: ==22593== Thread 3: ==22593== Conflicting load by thread 3 at 0x3401e1b328 size 4 ==22593==at 0x3401C0E090: write (in /lib64/libpthread-2.11.1.so) ==22593==by 0x41D99A: dbgprint (debug.c:894) ==22593==by 0x41DB08: dbgprintf (debug.c:987) ==22593==by 0x4258B3: asyncWriterThread (stream.c:939) ==22593==by 0x4A12280: vgDrd_thread_wrapper (drd_pthread_intercepts.c:272) ==22593==by 0x3401C06A39: start_thread (in /lib64/libpthread-2.11.1.so ) ==22593== Allocation context: BSS section of /lib64/libpthread-2.11.1.so ==22593== Other segment start (thread 1) ==22593==at 0x4A0993F: pthread_mutex_unlock (drd_pthread_intercepts.c:633) ==22593==by 0x427CEA: wtiSetState (wti.c:156) ==22593==by 0x427946: wtpAdviseMaxWorkers (wtp.c:519) ==22593==by 0x42C361: qqueueStart (queue.c:150) ==22593==by 0x40BA4A: init (syslogd.c:2400) ==22593==by 0x40C569: mainThread (syslogd.c:2856) ==22593==by 0x40DA16: realMain (syslogd.c:3554) ==22593==by 0x340101EB1C: (below main) (in /lib64/libc-2.11.1.so) ==22593== Other segment end (thread 1) ==22593==at 0x34010DE621: clone (in /lib64/libc-2.11.1.so) ==22593==by 0x3401C06333: do_clone.clone.0 (in /lib64/ libpthread-2.11.1.so) ==22593==by 0x3401C07001: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.11.1.so) ==22593==by 0x4A11DE8: pthread_cre...@* (drd_pthread_intercepts.c:409) ==22593==by 0x42795B: wtpAdviseMaxWorkers (wtp.c:520) ==22593==by 0x42C361: qqueueStart (queue.c:150) ==22593==by 0x40BA4A: init (syslogd.c:2400) ==22593==by 0x40C569: mainThread (syslogd.c:2856) ==22593==by 0x40DA16: realMain (syslogd.c:3554) ==22593==by 0x340101EB1C: (below main) (in /lib64/libc-2.11.1.so) ==22593== I can not identify which variable is at 0x3401e1b328. Given the alloc context, it looks like it is a static variable in the pthreads context. The code in question [1] does proper mutex locks before and after the relevant section. At least this is what I can identify. So I conclude that this is a problem in pthreads and I can safely create supressions for it. On the other hand, I do not understand why this only occurs in this instant, so I thought I better ask... Is this something that I can simply suppress or does it look like a real issue? If it is a real issue, can someone provide some advise on how to track it down? Maybe it's the thread cancellation code that triggers the above race report. Many system call wrappers in libpthread first check whether one or multiple threads are active. If multiple threads are active, the cancellation type is set to async before the system call and restored after the system call. Bart. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] novice drd user. Errors in std streams
On Wed, Apr 7, 2010 at 3:32 AM, Jorge Moraleda jorge.moral...@gmail.com wrote:
#include pthread.h
#include string
#include sstream
void *threadEntry(void *threadid)
{
long tid;
tid = (long)threadid;
std::string myString;
for (int i = 0; i5; i++) {
myString.clear();
pthread_yield();
}
pthread_exit(NULL);
}
int main (int argc, char *argv[])
{
pthread_t threads[2];
int rc;
long t;
std::ostringstream dummy;
dummy 0;
for(t=0; t2; t++) {
rc = pthread_create(threads[t], NULL, threadEntry, (void
*)t);
}
pthread_exit(NULL);
}
==19065== drd, a thread error detector
==19065== Copyright (C) 2006-2009, and GNU GPL'd, by Bart Van Assche.
==19065== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for
copyright info
==19065== Command: ./a.out
==19065==
==19065== Thread 3:
==19065== Conflicting load by thread 3 at 0x05134160 size 8
==19065== at 0x4EDF1D7: std::string::clear() (in
/usr/lib/libstdc++.so.6.0.13)
==19065== by 0x400A5B: threadEntry(void*) (threads.cpp:12)
==19065== by 0x4C32870: vgDrd_thread_wrapper
(drd_pthread_intercepts.c:272)
==19065== by 0x55E8A03: start_thread (pthread_create.c:300)
==19065== by 0x58DD80C: clone (clone.S:112)
==19065== Allocation context: BSS section of /usr/lib/libstdc++.so.6.0.13
==19065== Other segment start (thread 2)
==19065== at 0x58DD7D1: clone (clone.S:84)
==19065== by 0x55E893F: ??? (allocatestack.c:743)
==19065== by 0x676D90F: ???
==19065== Other segment end (thread 2)
==19065== at 0x58ACEB7: sched_yield (in /lib/libc-2.10.1.so)
==19065== by 0x400A60: threadEntry(void*) (threads.cpp:13)
==19065== by 0x4C32870: vgDrd_thread_wrapper
(drd_pthread_intercepts.c:272)
==19065== by 0x55E8A03: start_thread (pthread_create.c:300)
==19065== by 0x58DD80C: clone (clone.S:112)
==19065==
==19065== Conflicting load by thread 3 at 0x05134160 size 8
==19065== at 0x4EDE907: std::string::_M_mutate(unsigned long,
unsigned long, unsigned long) (in /usr/lib/libstdc++.so.6.0.13)
==19065== by 0x400A5B: threadEntry(void*) (threads.cpp:12)
==19065== by 0x4C32870: vgDrd_thread_wrapper
(drd_pthread_intercepts.c:272)
==19065== by 0x55E8A03: start_thread (pthread_create.c:300)
==19065== by 0x58DD80C: clone (clone.S:112)
==19065== Allocation context: BSS section of /usr/lib/libstdc++.so.6.0.13
==19065== Other segment start (thread 2)
==19065== at 0x58DD7D1: clone (clone.S:84)
==19065== by 0x55E893F: ??? (allocatestack.c:743)
==19065== by 0x676D90F: ???
==19065== Other segment end (thread 2)
==19065== at 0x58ACEB7: sched_yield (in /lib/libc-2.10.1.so)
==19065== by 0x400A60: threadEntry(void*) (threads.cpp:13)
==19065== by 0x4C32870: vgDrd_thread_wrapper
(drd_pthread_intercepts.c:272)
==19065== by 0x55E8A03: start_thread (pthread_create.c:300)
==19065== by 0x58DD80C: clone (clone.S:112)
==19065==
==19065== Conflicting load by thread 3 at 0x05134170 size 4
==19065== at 0x4EDE9B0: std::string::_M_mutate(unsigned long,
unsigned long, unsigned long) (in /usr/lib/libstdc++.so.6.0.13)
==19065== by 0x400A5B: threadEntry(void*) (threads.cpp:12)
==19065== by 0x4C32870: vgDrd_thread_wrapper
(drd_pthread_intercepts.c:272)
==19065== by 0x55E8A03: start_thread (pthread_create.c:300)
==19065== by 0x58DD80C: clone (clone.S:112)
==19065== Allocation context: BSS section of /usr/lib/libstdc++.so.6.0.13
==19065== Other segment start (thread 2)
==19065== at 0x58DD7D1: clone (clone.S:84)
==19065== by 0x55E893F: ??? (allocatestack.c:743)
==19065== by 0x676D90F: ???
==19065== Other segment end (thread 2)
==19065== at 0x58ACEB7: sched_yield (in /lib/libc-2.10.1.so)
==19065== by 0x400A60: threadEntry(void*) (threads.cpp:13)
==19065== by 0x4C32870: vgDrd_thread_wrapper
(drd_pthread_intercepts.c:272)
==19065== by 0x55E8A03: start_thread (pthread_create.c:300)
==19065== by 0x58DD80C: clone (clone.S:112)
==19065==
==19065== Conflicting store by thread 3 at 0x05134170 size 4
==19065== at 0x4EDE97D: std::string::_M_mutate(unsigned long,
unsigned long, unsigned long) (in /usr/lib/libstdc++.so.6.0.13)
==19065== by 0x400A5B: threadEntry(void*) (threads.cpp:12)
==19065== by 0x4C32870: vgDrd_thread_wrapper
(drd_pthread_intercepts.c:272)
==19065== by 0x55E8A03: start_thread (pthread_create.c:300)
==19065== by 0x58DD80C: clone (clone.S:112)
==19065== Allocation context: BSS section of /usr/lib/libstdc++.so.6.0.13
==19065== Other segment start (thread 2)
==19065== at 0x58DD7D1: clone (clone.S:84)
==19065== by 0x55E893F: ??? (allocatestack.c:743)
==19065== by 0x676D90F: ???
==19065== Other segment end (thread 2)
==19065== at 0x58ACEB7
Re: [Valgrind-users] novice drd user. Errors in std streams
On Tue, Apr 6, 2010 at 7:53 AM, Jorge Moraleda jorge.moral...@gmail.com wrote:
Dear all,
When I compile the following program with:
$ g++ -g -pthread threads.cpp
// begin program /
// file: threads.cpp
#include pthread.h
#include iostream
#include sstream
void *threadEntry(void *threadid)
{
long tid;
tid = (long)threadid;
for (int i = 0; i5; i++) {
std::stringstream myStream;
myStream this thread is tid;
std::string myString(myStream.str());
pthread_yield();
}
pthread_exit(NULL);
}
int main (int argc, char *argv[])
{
pthread_t threads[2];
int rc;
long t;
for(t=0; t2; t++) {
rc = pthread_create(threads[t], NULL, threadEntry, (void *)t);
}
pthread_exit(NULL);
}
// end program /
and run drd on it with:
$ valgrind --tool=drd ./a.out
I get the following output:
==16240== drd, a thread error detector
==16240== Copyright (C) 2006-2009, and GNU GPL'd, by Bart Van Assche.
==16240== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for
copyright info
==16240== Command: ./a.out
==16240==
==16240== Thread 3:
==16240== Conflicting load by thread 3 at 0x05132e98 size 1
==16240== at 0x4ED44C8: std::ostream
std::ostream::_M_insertlong(long) (in /usr/lib/libstdc++.so.6.0.13)
==16240== by 0x400C48: threadEntry(void*) (threads.cpp:12)
==16240== by 0x4C32870: vgDrd_thread_wrapper (drd_pthread_intercepts.c:272)
==16240== by 0x55E8A03: start_thread (pthread_create.c:300)
==16240== by 0x58DD80C: clone (clone.S:112)
==16240== Allocation context: BSS section of /usr/lib/libstdc++.so.6.0.13
==16240== Other segment start (thread 2)
==16240== at 0x4C29F2F: pthread_mutex_unlock (drd_pthread_intercepts.c:633)
==16240== by 0x4EA387E: std::locale::locale() (in
/usr/lib/libstdc++.so.6.0.13)
==16240== by 0x4E9FE5F: std::ios_base::_M_init() (in
/usr/lib/libstdc++.so.6.0.13)
==16240== by 0x4EB4768: std::basic_ioschar, std::char_traitschar
::init(std::basic_streambufchar, std::char_traitschar *) (in
/usr/lib/libstdc++.so.6.0.13)
==16240== by 0x4ED7DEA: std::basic_stringstreamchar,
std::char_traitschar, std::allocatorchar
::basic_stringstream(std::_Ios_Openmode) (in
/usr/lib/libstdc++.so.6.0.13)
==16240== by 0x400C21: threadEntry(void*) (threads.cpp:11)
==16240== by 0x4C32870: vgDrd_thread_wrapper (drd_pthread_intercepts.c:272)
==16240== by 0x55E8A03: start_thread (pthread_create.c:300)
==16240== by 0x58DD80C: clone (clone.S:112)
==16240== Other segment end (thread 2)
==16240== at 0x58ACEB7: sched_yield (in /lib/libc-2.10.1.so)
==16240== by 0x400C63: threadEntry(void*) (threads.cpp:14)
==16240== by 0x4C32870: vgDrd_thread_wrapper (drd_pthread_intercepts.c:272)
==16240== by 0x55E8A03: start_thread (pthread_create.c:300)
==16240== by 0x58DD80C: clone (clone.S:112)
==16240==
==16240== Conflicting load by thread 3 at 0x05132eb9 size 1
==16240== at 0x4ED44D3: std::ostream
std::ostream::_M_insertlong(long) (in /usr/lib/libstdc++.so.6.0.13)
==16240== by 0x400C48: threadEntry(void*) (threads.cpp:12)
==16240== by 0x4C32870: vgDrd_thread_wrapper (drd_pthread_intercepts.c:272)
==16240== by 0x55E8A03: start_thread (pthread_create.c:300)
==16240== by 0x58DD80C: clone (clone.S:112)
==16240== Allocation context: BSS section of /usr/lib/libstdc++.so.6.0.13
==16240== Other segment start (thread 2)
==16240== at 0x4C29F2F: pthread_mutex_unlock (drd_pthread_intercepts.c:633)
==16240== by 0x4EA387E: std::locale::locale() (in
/usr/lib/libstdc++.so.6.0.13)
==16240== by 0x4E9FE5F: std::ios_base::_M_init() (in
/usr/lib/libstdc++.so.6.0.13)
==16240== by 0x4EB4768: std::basic_ioschar, std::char_traitschar
::init(std::basic_streambufchar, std::char_traitschar *) (in
/usr/lib/libstdc++.so.6.0.13)
==16240== by 0x4ED7DEA: std::basic_stringstreamchar,
std::char_traitschar, std::allocatorchar
::basic_stringstream(std::_Ios_Openmode) (in
/usr/lib/libstdc++.so.6.0.13)
==16240== by 0x400C21: threadEntry(void*) (threads.cpp:11)
==16240== by 0x4C32870: vgDrd_thread_wrapper (drd_pthread_intercepts.c:272)
==16240== by 0x55E8A03: start_thread (pthread_create.c:300)
==16240== by 0x58DD80C: clone (clone.S:112)
==16240== Other segment end (thread 2)
==16240== at 0x58ACEB7: sched_yield (in /lib/libc-2.10.1.so)
==16240== by 0x400C63: threadEntry(void*) (threads.cpp:14)
==16240== by 0x4C32870: vgDrd_thread_wrapper (drd_pthread_intercepts.c:272)
==16240== by 0x55E8A03: start_thread (pthread_create.c:300)
==16240== by 0x58DD80C: clone (clone.S:112)
==16240==
==16240==
==16240== For counts of detected and suppressed errors, rerun with: -v
==16240== ERROR SUMMARY: 6 errors from 2 contexts (suppressed: 208 from 140)
My question is: Are the errors
Re: [Valgrind-users] novice drd user. Errors in std streams
On Tue, Apr 6, 2010 at 12:25 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Tue, Apr 6, 2010 at 2:17 PM, Bart Van Assche bvanass...@acm.org wrote:
On Tue, Apr 6, 2010 at 7:53 AM, Jorge Moraleda jorge.moral...@gmail.com
wrote:
Dear all,
When I compile the following program with:
$ g++ -g -pthread threads.cpp
// begin program /
// file: threads.cpp
#include pthread.h
#include iostream
#include sstream
void *threadEntry(void *threadid)
{
long tid;
tid = (long)threadid;
for (int i = 0; i5; i++) {
std::stringstream myStream;
myStream this thread is tid;
std::string myString(myStream.str());
pthread_yield();
}
pthread_exit(NULL);
}
int main (int argc, char *argv[])
{
pthread_t threads[2];
int rc;
long t;
for(t=0; t2; t++) {
rc = pthread_create(threads[t], NULL, threadEntry, (void *)t);
}
pthread_exit(NULL);
}
// end program /
and run drd on it with:
$ valgrind --tool=drd ./a.out
I get the following output:
==16240== drd, a thread error detector
==16240== Copyright (C) 2006-2009, and GNU GPL'd, by Bart Van Assche.
==16240== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for
copyright info
==16240== Command: ./a.out
==16240==
==16240== Thread 3:
==16240== Conflicting load by thread 3 at 0x05132e98 size 1
==16240== at 0x4ED44C8: std::ostream
std::ostream::_M_insertlong(long) (in /usr/lib/libstdc++.so.6.0.13)
==16240== by 0x400C48: threadEntry(void*) (threads.cpp:12)
==16240== by 0x4C32870: vgDrd_thread_wrapper
(drd_pthread_intercepts.c:272)
==16240== by 0x55E8A03: start_thread (pthread_create.c:300)
==16240== by 0x58DD80C: clone (clone.S:112)
==16240== Allocation context: BSS section of
/usr/lib/libstdc++.so.6.0.13
==16240== Other segment start (thread 2)
==16240== at 0x4C29F2F: pthread_mutex_unlock
(drd_pthread_intercepts.c:633)
==16240== by 0x4EA387E: std::locale::locale() (in
/usr/lib/libstdc++.so.6.0.13)
==16240== by 0x4E9FE5F: std::ios_base::_M_init() (in
/usr/lib/libstdc++.so.6.0.13)
==16240== by 0x4EB4768: std::basic_ioschar, std::char_traitschar
::init(std::basic_streambufchar, std::char_traitschar *) (in
/usr/lib/libstdc++.so.6.0.13)
==16240== by 0x4ED7DEA: std::basic_stringstreamchar,
std::char_traitschar, std::allocatorchar
::basic_stringstream(std::_Ios_Openmode) (in
/usr/lib/libstdc++.so.6.0.13)
==16240== by 0x400C21: threadEntry(void*) (threads.cpp:11)
==16240== by 0x4C32870: vgDrd_thread_wrapper
(drd_pthread_intercepts.c:272)
==16240== by 0x55E8A03: start_thread (pthread_create.c:300)
==16240== by 0x58DD80C: clone (clone.S:112)
==16240== Other segment end (thread 2)
==16240== at 0x58ACEB7: sched_yield (in /lib/libc-2.10.1.so)
==16240== by 0x400C63: threadEntry(void*) (threads.cpp:14)
==16240== by 0x4C32870: vgDrd_thread_wrapper
(drd_pthread_intercepts.c:272)
==16240== by 0x55E8A03: start_thread (pthread_create.c:300)
==16240== by 0x58DD80C: clone (clone.S:112)
==16240==
==16240== Conflicting load by thread 3 at 0x05132eb9 size 1
==16240== at 0x4ED44D3: std::ostream
std::ostream::_M_insertlong(long) (in /usr/lib/libstdc++.so.6.0.13)
==16240== by 0x400C48: threadEntry(void*) (threads.cpp:12)
==16240== by 0x4C32870: vgDrd_thread_wrapper
(drd_pthread_intercepts.c:272)
==16240== by 0x55E8A03: start_thread (pthread_create.c:300)
==16240== by 0x58DD80C: clone (clone.S:112)
==16240== Allocation context: BSS section of
/usr/lib/libstdc++.so.6.0.13
==16240== Other segment start (thread 2)
==16240== at 0x4C29F2F: pthread_mutex_unlock
(drd_pthread_intercepts.c:633)
==16240== by 0x4EA387E: std::locale::locale() (in
/usr/lib/libstdc++.so.6.0.13)
==16240== by 0x4E9FE5F: std::ios_base::_M_init() (in
/usr/lib/libstdc++.so.6.0.13)
==16240== by 0x4EB4768: std::basic_ioschar, std::char_traitschar
::init(std::basic_streambufchar, std::char_traitschar *) (in
/usr/lib/libstdc++.so.6.0.13)
==16240== by 0x4ED7DEA: std::basic_stringstreamchar,
std::char_traitschar, std::allocatorchar
::basic_stringstream(std::_Ios_Openmode) (in
/usr/lib/libstdc++.so.6.0.13)
==16240== by 0x400C21: threadEntry(void*) (threads.cpp:11)
==16240== by 0x4C32870: vgDrd_thread_wrapper
(drd_pthread_intercepts.c:272)
==16240== by 0x55E8A03: start_thread (pthread_create.c:300)
==16240== by 0x58DD80C: clone (clone.S:112)
==16240== Other segment end (thread 2)
==16240== at 0x58ACEB7: sched_yield (in /lib/libc-2.10.1.so)
==16240== by 0x400C63: threadEntry(void*) (threads.cpp:14)
==16240== by 0x4C32870: vgDrd_thread_wrapper
(drd_pthread_intercepts.c:272)
==16240
[Valgrind-users] FAQ: cross-compiling Valgrind / Valgrind cross-compilation
From time to time Valgrind users ask how the Valgrind source code can
be cross-compiled. While cross-compiling Valgrind is no different of
cross-compiling any other project that is based on autotools, I'm
posting here a script that should help those who are not familiar with
cross-compilation. What the script does is to check out the Valgrind
source tree from the Subversion repository in a subdirectory of the
current working directory, set up a directory $PWD/bin with soft links
to the cross-compilation tools, add this directory to the path, and
invoke autogen.sh, configure and make. Setting up a directory with
soft links to the cross compilation tools is more convenient than
having to pass the variables CC, AS, LD etc. individually to
configure.
#!/bin/bash
# Make sure to adjust the four variables below such that these match your setup.
CROSS_TOOLS_PREFIX=/opt/cell/bin/ppu-
PREFIX=$HOME/valgrind-inst
TARGET=powerpc64-unknown-linux
HOST=x86_64-linux-gnu
valgrind_dir=valgrind-trunk
svn co svn://svn.valgrind.org/valgrind/trunk ${valgrind_dir} || exit $?
cd ${valgrind_dir} || exit $?
rm -rf bin
mkdir -p bin
(
cd bin
for f in ${CROSS_TOOLS_PREFIX}*
do
ln -s $f $TARGET-${f#${CROSS_TOOLS_PREFIX}}
done
)
export PATH=${PATH}:$PWD/bin
./autogen.sh || exit $?
./configure\
--build=$HOST \
--host=$TARGET \
--prefix=$PREFIX \
--target=$TARGET \
--enable-tls \
|| exit $?
make -s || exit $?
make -s check || exit $?
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Cross compiling valgrind 3.5.0 for ppc
On Wed, Feb 10, 2010 at 11:27 PM, Stephen Williams st...@icarus.com wrote: I'm on an x86_64 workstation (Linux 2.6) trying to cross compile for ppc (Linux 2.4). I can't even get past the configure, it fails with the error: checking for /proc/self/fd... configure: error: cannot check for file existence when cross compiling This has been reported some time ago as bug #204843 (https://bugs.kde.org/show_bug.cgi?id=204843) and has been fixed on the trunk and on the 3.5 branch. Bart. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Understanding DRD output
On Wed, Dec 9, 2009 at 2:23 PM, Mathieu Malaterre mathieu.malate...@gmail.com wrote: I am discovering DRD tool today, after reading the following documentation: http://valgrind.org/docs/manual/drd-manual.html#drd-manual.data-races I am trying to apply this to the following output (*). According to the doc, I need to: Start at the bottom of both call stacks, and count the number stack frames with identical function name, file name and line number. In the above example the three bottommost frames are identical (clone, start_thread and vg_thread_wrapper). However in my case, there does not seems to be any identical function name/filename/line number. can I still deduce anything from that particular output ? (*) ==15069== Thread 2: ==15069== Conflicting load by thread 2 at 0x00650958 size 8 ==15069== at 0x77FEEFD: std::basic_ostreamchar, std::char_traitschar std::__ostream_insertchar, std::char_traitschar (std::basic_ostreamchar, std::char_traitschar , char const*, long) (in /usr/lib/libstdc++.so.6.0.13) The above tells you that the conflicting load was caused by a memory access inside the libstdc++ code for sending a string (char const*) to a stream. As you can see in the source code of this function (see also file libstdc++-v3/include/bits/ostream_insert.h in the gcc source tree), this function creates a temporary object of type sentry (see also http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-3.4/classstd_1_1basic__istream_1_1sentry.html for more information). The constructor of sentry objects uses the locale to find out whether a character is whitespace or not. [...] ==15069== Allocation context: BSS section of de/Csm-gcc/CodeGenerator/Testing/GeneratedEpidemiology/Bin/main This tells you that the conflicting access occurred on a variable in a BSS section (a global or a static variable). [ ... ] ==15069== Other segment end (thread 1) ==15069== at 0x4C26668: pthread_mutex_lock (drd_pthread_intercepts.c:580) ==15069== by 0x77CE1BE: std::locale::locale() (in /usr/lib/libstdc++.so.6.0.13) ==15069== by 0x77CA82F: std::ios_base::_M_init() (in /usr/lib/libstdc++.so.6.0.13) ==15069== by 0x77DF228: std::basic_ioschar, std::char_traitschar ::init(std::basic_streambufchar, std::char_traitschar *) (in /usr/lib/libstdc++.so.6.0.13) ==15069== by 0x7802652: std::basic_stringstreamchar, std::char_traitschar, std::allocatorchar ::basic_stringstream(std::_Ios_Openmode) (in /usr/lib/libstdc++.so.6.0.13) [ ... ] The above information is an additional hint that the conflicting access is probably caused by access to locale information. What is not yet clear to me is whether the conflicting memory access is caused by libstdc++ or by the code using libstdc++, e.g. because a stringstream object is being accessed from more than one thread. Bart. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] DRD error report...
On Thu, Dec 10, 2009 at 1:08 AM, Aleksander valgrind-us...@aleksander.es wrote: Can someone explain the error shown below? It's in a glib-based application, and it seems that DRD doesn't like the call to send() in libpthread while creating a new thread at the same time... Why is this wrong? [ ... ] ==19314== Conflicting load by thread 6 at 0x39ba019310 size 4 ==19314== at 0x39B9E0D192: send (in /lib64/libpthread-2.5.so) ==19314== by 0x4C342D0: __jardin_connection_module_send_impl (jardin_connection_module.c:863) [ ... ] ==19314== Allocation context: BSS section of /lib64/libpthread-2.5.so [ ... ] DRD uses the Valgrind core to print a call stack when a conflicting memory access has been detected. I'm not sure the library information in the above call stack is correct: as far as I know send() is a function that has been implemented in libc and not in libpthread. If it's not clear why DRD reports a conflicting memory access, the following will help: - Start from the address on which a conflicting memory access has been reported, and find out with which data structure in the source code program this address corresponds. If you don't have a clue, inspect your program at the time the conflicting memory access was reported with --db-attach=yes. - Find out where the data structure has been allocated. If the memory has been allocated dynamically, insert a DRD_TRACE_VAR(...) statement just after the allocation. If it's a global or static variable, insert the DRD_TRACE_VAR(...) macro in a function that is called before the data structure is used. See also the Valgrind manual for more information about the DRD_TRACE_VAR() macro. Bart. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Huge amount of warnings from memcheck
On Mon, Nov 16, 2009 at 11:35 AM, Andre Naujoks nauts...@googlemail.comwrote: There was no need to recompile valgrind. Only the install of libc6-dbg was needed. After that, all was fine with both the debian valgrind and the one from svn. The Debian maintainers have to recompile Valgrind such that the aforementioned error message appears when Valgrind is started instead of Valgrind reporting large numbers of false positives. Please report this to the Debian maintainers. Bart. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind errors on PPC
On Fri, Oct 16, 2009 at 11:46 PM, Ajay Kalambur kalam...@gmail.com wrote: I cross compiled valgrind for ppc and now run valgrind on ppc But i get the following error when i run valgrind and it throws tons of errors for every programWARNING: Serious error when reading debug info --28416-- When reading debug info from /nobackup/akalambu/cometdev1012/linkfarm/ppc/lib/valgrind/vgpreload_core-ppc32-linux.so: --28416-- Can't make sense of .sdata section mapping --28416-- Reading syms from /nobackup/akalambu/cometdev1012/linkfarm/ppc/lib/valgrind/vgpreload_drd-ppc32-linux.so (0xffac000) --28416-- WARNING: Serious error when reading debug info --28416-- When reading debug info from /nobackup/akalambu/cometdev1012/linkfarm/ppc/lib/valgrind/vgpreload_drd-ppc32-linux.so: --28416-- Can't make sense of .sdata section mapping I see these errors Which output does your cross-compiler print when started with command-line option -v ? Bart. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] race condition reported in pthread_create
On Fri, Oct 9, 2009 at 1:54 PM, Brian Modra br...@zwartberg.com wrote:
in my Open Source project, The Karoo Project, I was rigorously testing
using helgrind, and consistently got a report of a possible race
condition in pthread_create. This seemed strange, and I checked out
the address it was reporting, which turned out to be a variable
allocated on the stack inside the call to pthread_create, or in a
function it called inside the pthreads library.
So I created a test program which does reproduce the same race
condition waring. (Attached)
To compile and test:
gcc -o z z.c -lpthread
valgrind --tool=helgrind ./z
Note that if I don't pass the pointer to the element in the data
array, then there is no race condition reported.
But this memory is not written or read anywhere in my program.
I wonder if anyone else has experienced this... I need to work out if
this is a valgrind bug, or a pthreads bug, or am I missing something?
The race reported by Helgrind might be one of the benign races
triggered by the NPTL during thread creation.
As you can see in glibc-2.34567-NPTL-helgrind.supp this file already
contains the following suppression pattern:
{
helgrind-glibc2X-109
Helgrind:Race
fun:start_thread
}
What you can do is to add a suppression pattern for the output you
posted, create a bug report and include the new suppression pattern in
your bug report.
Bart.
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Warnings running 3.5.0 on a Cell BE processor
On Mon, Aug 31, 2009 at 7:26 PM, Phil Sandersppjs...@us.ibm.com wrote: I just tried the 3.5.0 version of valgrind on Cell BE and was seeing a number of these errors --21076-- WARNING: Serious error when reading debug info --21076-- When reading debug info from /spu/spethread-21076-124700480/psmap: --21076-- can't read file to inspect ELF header Have I misconfigured things (I did not do any thing special to configure), a problem, or maybe an issue with my application build? A lot of code has been changed in the 3.5.0 release, so it's not immediately clear whether this is a configuration issue or a Valgrind issue. Can you please create a bug report for this issue and include the Valgrind output with -v -d added to the Valgrind command line options ? Can you also verify whether this is a new issue in 3.5.0 or whether this also occurred with 3.4.1 ? Bart. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Supressing helgrind false positives with an annotation?
On Thu, Aug 27, 2009 at 3:51 AM, Jeff Johnsonn3...@mac.com wrote: I'm using helgrind from 3.5.0 on OPENMP code. I have a lazily malloc'd pthread mutex in a static global variable that helgrind detects. I'd like to disable the warning somehow in code, not with a suppression, so that I can look at more interesting errors. So far I've failed to be able to annotate the code to avoid the warning. I'm not familiar with all the details of Helgrind. But I know that DRD has a macro called DRD_IGNORE_VAR() that allows to suppress data race reports on any memory range. Bart. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] suppression files with valgrind 3.5.0
On Fri, Aug 21, 2009 at 12:02 AM, Mogens Lindholdt Lauridsenm...@bang-olufsen.dk wrote: Interesting..., so what about cross-compiling? I build valgrind on Suse x86 for PPC32 using a build script like this: export CC=/opt/wrsysroot/x86-linux2/powerpc-wrs-linux-gnu-ppc_603e-glibc_small-gcc export CXX=/opt/wrsysroot/x86-linux2/powerpc-wrs-linux-gnu-ppc_603e-glibc_small-g++ export LD=/opt/wrsysroot/x86-linux2/powerpc-wrs-linux-gnu-ppc_603e-glibc_small-ld export LDFLAGS=-L/home/mln/evb/rootfs/usr/lib tar -xjf valgrind-3.3.1_with_mfspr_patch.tar.bz2 cd valgrind-3.3.1 ./configure --prefix=/home/mln/valgrind/install_debug --enable-shared --host=ppc-linux --target=ppc-linux --enable-debug --disable-tls || exit 1 make || exit 1 make install || exit 1 Will this give me the correct suppression files? Cross-compilation was broken in 3.3.0 but works fine with 3.4.0 and 3.4.1 and should still work fine with 3.5.0 (see also https://bugs.kde.org/show_bug.cgi?id=162295). Bart. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] suppression files with valgrind 3.5.0
On Sun, Aug 23, 2009 at 10:41 AM, Bart Van Asschebart.vanass...@gmail.com wrote: On Fri, Aug 21, 2009 at 12:02 AM, Mogens Lindholdt Lauridsenm...@bang-olufsen.dk wrote: Interesting..., so what about cross-compiling? Cross-compilation was broken in 3.3.0 but works fine with 3.4.0 and 3.4.1 and should still work fine with 3.5.0 (see also https://bugs.kde.org/show_bug.cgi?id=162295). Update: cross-compilation is broken again in 3.5.0 -- see also https://bugs.kde.org/show_bug.cgi?id=204843. I assume that a fix will be included in 3.5.1. Bart. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Strange helgrind dataraces reports involving std::string
On Thu, Jul 30, 2009 at 2:05 PM, Alexander Potapenkogli...@google.com wrote: There's also a link to a related bug on gcc.gnu.org there: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518 If I interpret the above bug report correctly, the gcc maintainers confirmed that the std::string implementation of the libstdc++ library included with gcc versions 4.2.2, 4.3.2, 4.4.0 and 4.5.0 triggers a data race. Bart. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Address 0xNNNNN is N bytes inside a block of size N alloc'd
On Mon, Jul 27, 2009 at 12:42 PM, Pavel Shevaevpacha.shev...@gmail.com wrote: Folks, could you please tell what exactly this error message mean? I googled around the documentation and found nothing... The text you quoted in the title of this e-mail is not an error message by itself, but a clarification of the error message printed above that message. It would help if you could post the entire message. Bart. -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] [Valgrind-developers] bug 100628
On Fri, Jul 24, 2009 at 11:12 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
https://bugs.kde.org/show_bug.cgi?id=100628 concerns a program like this:
#include stdlib.h
#include valgrind.h
int main(void)
{
char* x;
x = malloc(1000);
VALGRIND_MALLOCLIKE_BLOCK(x, /*szB*/ 16, /*rzB*/0, /*is_zeroed*/0);
VALGRIND_MALLOCLIKE_BLOCK(x+100, /*szB*/ 32, /*rzB*/0, /*is_zeroed*/0);
VALGRIND_MALLOCLIKE_BLOCK(x+200, /*szB*/ 64, /*rzB*/0, /*is_zeroed*/0);
VALGRIND_MALLOCLIKE_BLOCK(x+300, /*szB*/128, /*rzB*/0, /*is_zeroed*/0);
return 0;
}
It's a simplified version of a real problem, where a user implements a
custom allocator on top of malloc(). They use malloc() to allocate a
big chunk of memory, and then hand out pieces of it, using
MALLOCLIKE_BLOCK to mark those pieces as logically separate heap
blocks. Currently the leak checker barfs on it because it can't
handle overlapping heap blocks.
I have a patch that tolerates overlaps such as these, where a custom
block falls entirely within a malloc()'d block. But there's a design
choice to be made. In such a case, what do we do with the malloc()'d
block?
(1) Ignore it completely when leak checking
(2) Consider it when leak checking
It's unclear to me which of these is preferable. (1) treats the
malloc() much as a mmap() or brk() would be treated, which is arguably
desirable, as many allocators are built on mmap() and/or brk() and so
treating malloc() in the same way makes some sense. But (2) involves
less special-casing, and is thus slightly easier to do than (1).
Anyone have any preferences?
My suggestion is to require that the user makes it clear to Valgrind
that the memory allocated by the malloc() call in the example won't be
used directly but will be handed out in pieces to the client program.
Bart.
--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] SCALI MPI, Infiniband and Valgrind
On Fri, Jun 26, 2009 at 6:24 PM, Dominic Walshdwa...@abingdon.oilfield.slb.com wrote: I have just been trying out SCALI MPI with Valgrind and have observed that when running across multiple nodes the process seem to end up spinning in MPI_Init. Smaller problems running with shared memory appear fine. The configuration is: 8 Nodes connected by Infiniband 2 Sockets/Node with 1 MPI process each Plenty of spare memory No competing processes – memcheck is at 100% My hunch is there is weird packet dropping effect but hoping someone out there has an idea. Was hoping I could tell Valgrind to skip instrumenting libmpi.so? Either I didn’t read the manual well enough or it breaks a fundamental principle (which I suspect it might) Have you noticed the thread about Valgrind and memcpy() on the ofa-general mailing list ? See also http://lists.openfabrics.org/pipermail/general/2009-June/060037.html. Bart. -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] drd: drd_mutex.c:383 (mutex_unlock): Assertion 'p-mutex_type == mutex_type' failed
On Fri, May 15, 2009 at 10:06 AM, Andy Howell andyhow...@austin.rr.com wrote: Bart Van Assche wrote: On Fri, May 15, 2009 at 9:33 AM, Andy Howell andyhow...@austin.rr.com wrote: Hello, I'm seeing this with 3.4.1 compiled on fedora 9. Just before that I see: ==14457== Mutex reinitialization: mutex 0x4c621a8, recursion count 0, owner 0. ==14457== at 0x4A0B4A4: pthread_mutex_init (in /usr/lib64/valgrind/amd64-linux/vgpreload_drd.so) ==14457== by 0x546DCE: Mutex::create(Mutex::MutexType) (thread.cpp:1023) ==14457== by 0x4DDA85: AsyncDNSImpl::init(Select*, ThreadAccess, unsigned int) (async_dns.cpp:1518) ==14457== by 0x4DE47E: AsyncDNSImpl::create(Select*, EventManager*, ThreadAccess, unsigned int) (async_dns.cpp:87) ==14457== by 0x4E2FAF: AsyncDNS::create(Select*, EventManager*, ThreadAccess, unsigned int) (async_dns.cpp:64) ==14457== by 0x412809: Agent::init(int, char**) (agent.cpp:1838) ==14457== by 0x414C77: main (agent.cpp:2559) ==14457== mutex 0x4c621a8 was first observed at: ==14457== at 0x4A0B4A4: pthread_mutex_init (in /usr/lib64/valgrind/amd64-linux/vgpreload_drd.so) ==14457== by 0x546D9E: Mutex::create(Mutex::MutexType) (thread.cpp:1002) ==14457== by 0x4DDA85: AsyncDNSImpl::init(Select*, ThreadAccess, unsigned int) (async_dns.cpp:1518) ==14457== by 0x4DE47E: AsyncDNSImpl::create(Select*, EventManager*, ThreadAccess, unsigned int) (async_dns.cpp:87) ==14457== by 0x4E2FAF: AsyncDNS::create(Select*, EventManager*, ThreadAccess, unsigned int) (async_dns.cpp:64) ==14457== by 0x412809: Agent::init(int, char**) (agent.cpp:1838) ==14457== by 0x414C77: main (agent.cpp:2559) ==14457== ??? mutex 0x4c621a8: type changed from 3 into 1 Looks like drd thinks the mutex type is changing from a default type to a recursive type mutex. I don't understand why it thinks the mutex is being re-initialized. Both call stacks contain the same functions and line numbers. In my code, this initialization is only done once. Any ideas? Please look more carefully: the second call stack refers to file thread.cpp, line 1002, while the first call stack refers to file thread.cpp line 1023. So the above message most likely reports what it says: mutex reinitialization. You confirmed its time for me to call it a night. I double checked them before sending the mail, but was obviously too bleary-eyed to catch it. No problem. And thanks for reporting the assertion failure. By this time the assertion failure you reported has been fixed both on the trunk and on the Valgrind 3.4.x branch. Bart. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] dlmalloc and helgrind (drd?) ?
On Thu, Apr 30, 2009 at 7:37 PM, daniel.delg...@interactivedata.com wrote: Thusfar the helgrind reports have gone away each of the times I ran this application without dlmalloc. Are you familiar with the VALGRIND_MALLOCLIKE_BLOCK() and VALGRIND_FREELIKE_BLOCK() macro's defined in the header file valgrind/valgrind.h ? These macro's allow a memory allocation library to tell a Valgrind tool about its allocation and deallocation activities, and could be used to instrument the dlmalloc source code. Several Valgrind tools, including the trunk version of DRD, support these macro's. Bart. -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Support for cross compiling
On Mon, Mar 16, 2009 at 1:48 PM, Florian Krohm brit...@acm.org wrote: On Monday 16 March 2009 6:04:54 am Mansuri Wasim-WCFJ43 wrote: How to do the cross compilation for valgrind source code? ./configure --host=your-cross-target --enable-tls or --disable-tls. But you need to give one of them because checking for TLS cannot be done during a cross-compile By the way, from Valgrind version 3.4.0 on you do no longer have to specify --enable-tls or --disable-tls when cross-compiling Valgrind. Bart. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] problem running valgrind
On Mon, Feb 23, 2009 at 9:59 PM, Rohit rohit.tanne...@ngc.com wrote: I have a problem running valgrind. I can comple and run it just fine on the development system, but not the target. When I try to run there, I get a floating point exception at startup when I try to run valgrind. Has anyone seen this before? If so, can you provide some insight into this? Which Valgrind version are you using, and what is the CPU architecture of the target ? Bart. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind 3.4 on PPC32
On Thu, Feb 19, 2009 at 4:54 PM, linux user linuxuse...@gmail.com wrote: Has anybody had any success with Valgrind 3.4 on PPC32?I'd appreciate your input. According to the e-mails posted on the valgrind-users mailing list during the last few weeks, several people are running Valgrind 3.4 successfully on embedded PPC32 systems. Bart. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Need User manual for Valgrind 3.2.3 urgently
On Thu, Feb 19, 2009 at 1:01 AM, linux user linuxuse...@gmail.com wrote: Could someone please mail me a copy if they have one?I'm not able to build the doc for some reason. Did you already try the command below ? make -C docs html-docs xdg-open docs/html/index.html Bart. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] problem running valgrind on 64-bit machine
On Mon, Feb 9, 2009 at 2:58 PM, Paul Graham pgra...@oasys-ds.com wrote: I am trying to install and run valgrind 3.4.0 on a 64-bit linux system. I'm getting an error I don't understand: % uname -a Linux xxx.yyy.com 2.6.9-5.ELsmp #1 SMP Wed Jan 5 19:29:47 EST 2005 x86_64 x86_64 x86_64 GNU/Linux % which valgrind ~/valgrind/bin/valgrind % valgrind ls valgrind: failed to start tool 'memcheck' for platform 'amd64-linux': No such file or directory % What does this message even mean? Do I need to set up some environment variable? I built valgrind 3.4.0 on another machine, a 32-bit linux system, and it works just fine, running from my home directory. I'm not sure what's different. This thread probably contains the information you are looking for: http://thread.gmane.org/gmane.comp.debugging.valgrind/8203/focus=8212. Bart. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Pthread error not detected by DRD and Helgrind
On Fri, Feb 6, 2009 at 8:19 PM, Julian Seward jsew...@acm.org wrote: If you can suggest some criteria that allows to distinguish the case you consider an error, from a safe destruction of a barrier, that would be very helpful. But given that the POSIX spec is basically broken, I don't see how it would be possible to construct such a criteria. How about comparing the vector clocks of the most recent barrier_wait() calls with the vector clock of the thread destroying the barrier ? This should allow to find out whether or not barrier_wait() calls and a barrier_destroy() call that explicitly destroys a barrier or any free() call that implicitly destroys a barrier were ordered via a synchronization operation. Bart. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Possible data race during read of size 4
On Thu, Jan 29, 2009 at 9:42 AM, jody jody@gmail.com wrote: Phrased differently: do threads which exited, but who weren't joined use up any resources? If I remember correctly, the thread stack of non-detached threads is freed by pthread_join(). Since the default stack size is 2 MB on Linux, not calling pthread_join will definitely cause a memory leak. Bart. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Possible data race during read of size 4
On Thu, Jan 29, 2009 at 9:58 AM, jody jody@gmail.com wrote:
I tried out DRD, but even though i read the DRD manual,
i don't really understand the output (i used --tool=drd --var-info=yes -v)
I get many messages concerning the same line, a print statement
performed by the thread just before it exits the start func:
==19067== Conflicting store by thread 2/2 at 0x0400c018 size 4
==19067==at 0x9E841C: mempcpy (in /lib/libc-2.7.so)
==19067==by 0x9B3814: vfprintf (in /lib/libc-2.7.so)
==19067==by 0x9BC9B2: printf (in /lib/libc-2.7.so)
==19067==by 0x8049745: OutputCollector::threadStart(void*)
(OutputCollector.cpp:242)
==19067==by 0x400920A: vg_thread_wrapper (drd_pthread_intercepts.c:193)
==19067==by 0xB0950A: start_thread (in /lib/libpthread-2.7.so)
==19067==by 0xA4AB2D: clone (in /lib/libc-2.7.so)
Can you please test either the Valgrind trunk or recompile the
Valgrind sources after having applied the patch you can find below ?
Instructions for downloading and building the Valgrind trunk can be
found here: http://www.valgrind.org/downloads/repository.html
The above data race reported by DRD refers to internal variables of
the glibc library. The stdio implementation in glibc uses its own
locking implementation, and this implementation uses inline functions.
This makes it impossible for threading tools to intercept the locking
primitives used in the glibc stdio library. The patch below suppresses
data race reports where the top stack frame is in glibc.
Modified: trunk/glibc-2.X-drd.supp
===
--- trunk/glibc-2.X-drd.supp2009-01-29 09:20:44 UTC (rev 9086)
+++ trunk/glibc-2.X-drd.supp2009-01-29 09:57:22 UTC (rev 9087)
@@ -48,6 +48,11 @@
fun:backtrace_symbols
}
{
+ libc-stdio
+ drd:ConflictingAccess
+ obj:/lib*/libc-*
+}
+{
libc
drd:ConflictingAccess
fun:__libc_enable_asynccancel
Thanks,
Bart.
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Possible data race during read of size 4
On Thu, Jan 29, 2009 at 12:34 PM, jody jody@gmail.com wrote: I modified the glibc-2.X-drd.supp and recompiled valgrind. It works - the printf() are not complained about anymore. Thanks for testing. This fix will be included in Valgrind 3.4.1. Bart. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Syscall param socketcall.accept(addr) points to unaddressable byte(s)
On Wed, Jan 28, 2009 at 11:06 AM, jody jody@gmail.com wrote: Hi I have checked a TCP-server which i wrote with valgrind-3.4.0, and encountered these errors: ==15611== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 17 from 1) ==15611== ==15611== 1 errors in context 1 of 2: ==15611== Syscall param socketcall.accept(addr) points to unaddressable byte(s) ==15611==at 0xA4BA01: accept (in /lib/libc-2.7.so) ==15611==by 0x98D38F: (below main) (in /lib/libc-2.7.so) ==15611== Address 0xbea43000 is not stack'd, malloc'd or (recently) free'd ==15611== ==15611== 1 errors in context 2 of 2: ==15611== Syscall param socketcall.accept(addrlen_in) points to uninitialised byte(s) ==15611==at 0xA4BA01: accept (in /lib/libc-2.7.so) ==15611==by 0x98D38F: (below main) (in /lib/libc-2.7.so) ==15611== Address 0xbea4233c is on thread 1's stack I simplified the server to the point where it only calls accept (see below), and the errors still prevail. I compile it with g++ -g -Wall dummysrv.cpp -o dummysrv (g++ (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33)) What do these messages mean and how can i fix that? The position below main is a little bit vague... I'm not sure this is the cause of the above message, but the call of accept() is not correct: the third argument of accept() is a value-result parameter, and should be initialized before passing it to accept(). Bart. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] disInstr(ppc): unhandled instruction: 0x7D20009... on PPC 440EPX
On Mon, Jan 26, 2009 at 11:34 PM, tic tac hotsbl...@hotmail.com wrote: Date: Thu, 15 Jan 2009 16:52:15 +0100 From: bart.vanass...@gmail.com To: hotsbl...@hotmail.com Subject: Re: [Valgrind-users] disInstr(ppc): unhandled instruction: 0x7D20009... on PPC 440EPX CC: valgrind-users@lists.sourceforge.net On Thu, Jan 15, 2009 at 4:18 PM, tic tac hotsbl...@hotmail.com wrote: In regards to the following bug: http://bugs.kde.org/show_bug.cgi?id=180513 I am trying to gather information as to where I should start if I want to pinpoint which lines of code are leading to this problem. Also is there any documentation about fixing these unhandled instructions? The following Valgrind flags will be helpful while modifying VEX: --trace-flags and --trace-notbelow. These flags tell Valgrind to show how it translates assembly instructions into the intermediate representation through VEX and the other way around. An example: $ ./vg-in-place --tool=none --trace-flags=1001 --trace-notbelow=0 /bin/date I did the run with the mentioned options, I am getting 7Mo compressed in a log file. How do I go from there? Maybe I was not clear enough: the command-line options --trace-flags and --trace-notbelow are a.o. helpful for verifying whether modifications of the VEX library are OK -- I was not asking to send me the output of a Valgrind run with these options enabled. Bart. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
