You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(4) |
2
(3) |
3
|
|
4
(2) |
5
(4) |
6
(10) |
7
(11) |
8
(3) |
9
(7) |
10
|
|
11
(1) |
12
(7) |
13
(9) |
14
(14) |
15
(7) |
16
|
17
(1) |
|
18
|
19
(1) |
20
(5) |
21
(2) |
22
(3) |
23
(1) |
24
|
|
25
|
26
(1) |
27
(1) |
28
(4) |
29
(3) |
30
(1) |
|
|
From: Cyril S. <cyr...@fr...> - 2010-04-07 08:47:08
|
Stewart Smith a écrit : > On Wed, 07 Apr 2010 10:16:31 +0200, Cyril Scetbon <cyr...@fr...> wrote: > >> 100407 10:11:45 InnoDB: Error: cannot allocate 1610629120 bytes of >> InnoDB: memory with malloc! Total allocated memory >> InnoDB: by InnoDB 23965696 bytes. Operating system errno: 0 >> InnoDB: Check if you should increase the swap file or >> InnoDB: ulimits of your operating system. >> InnoDB: On FreeBSD check you have compiled the OS with >> InnoDB: a big enough maximum process size. >> InnoDB: Note that in most 32-bit computers the process >> >> Outch ! you think the process is trying to allocate 1.6GB+~0.8GB+(more >> memory for mysql) and that's over the max memory per process on x86 ? >> > > Under valgrind on 32bit... could be getting close. > > try with a smaller buffer pool, or just use 64bit :) > > seems to work better if I assign less memory to InnoDB. Thanks for your help ! -- Cyril SCETBON |
|
From: Cyril S. <cyr...@fr...> - 2010-04-07 08:32:51
|
John Reiser a écrit : >> When I start MySQL, InnoDB engine allocate his buffer pool without any >> issue. It's not the same when I launch it with Valgrind :( >> What can I do to resolve this issue ? >> > > Post a copy of the error message(s). It is necessary first to identify > _which_ error(s). Include the machine architecture (i686, x86_64, etc.) > and the operating system. In other words, give a decent bug report. > > Speculating that you may be running Linux on i686, then _sometimes_ > it is possible to obtain an extra 0.8GB of address space by running > the i686 version of the application and valgrind on a x86_64 machine. > > I understand. Here are the information you asked for : Linux host01 2.6.24.2 #1 SMP Wed Feb 20 15:40:12 CET 2008 i686 GNU/Linux the error message is the following : 100407 10:11:45 InnoDB: Error: cannot allocate 1610629120 bytes of InnoDB: memory with malloc! Total allocated memory InnoDB: by InnoDB 23965696 bytes. Operating system errno: 0 InnoDB: Check if you should increase the swap file or InnoDB: ulimits of your operating system. InnoDB: On FreeBSD check you have compiled the OS with InnoDB: a big enough maximum process size. InnoDB: Note that in most 32-bit computers the process Outch ! you think the process is trying to allocate 1.6GB+~0.8GB+(more memory for mysql) and that's over the max memory per process on x86 ? Regards -- Cyril SCETBON |
|
From: Stewart S. <st...@fl...> - 2010-04-07 08:28:32
|
On Wed, 07 Apr 2010 10:16:31 +0200, Cyril Scetbon <cyr...@fr...> wrote: > 100407 10:11:45 InnoDB: Error: cannot allocate 1610629120 bytes of > InnoDB: memory with malloc! Total allocated memory > InnoDB: by InnoDB 23965696 bytes. Operating system errno: 0 > InnoDB: Check if you should increase the swap file or > InnoDB: ulimits of your operating system. > InnoDB: On FreeBSD check you have compiled the OS with > InnoDB: a big enough maximum process size. > InnoDB: Note that in most 32-bit computers the process > > Outch ! you think the process is trying to allocate 1.6GB+~0.8GB+(more > memory for mysql) and that's over the max memory per process on x86 ? Under valgrind on 32bit... could be getting close. try with a smaller buffer pool, or just use 64bit :) -- Stewart Smith |
|
From: Konstantin S. <kon...@gm...> - 2010-04-07 04:20:02
|
The race on _M_mutate is (most likely) the one discussed at http://permalink.gmane.org/gmane.comp.debugging.valgrind/10043 <http://permalink.gmane.org/gmane.comp.debugging.valgrind/10043>--kcc On Tue, Apr 6, 2010 at 4:14 PM, Jorge Moraleda <jor...@gm...>wrote: > On Tue, Apr 6, 2010 at 3:30 AM, Bart Van Assche <bva...@ac...> > wrote: > > On Tue, Apr 6, 2010 at 12:25 PM, Konstantin Serebryany > > <kon...@gm...> wrote: > >> > >> > >> On Tue, Apr 6, 2010 at 2:17 PM, Bart Van Assche <bva...@ac...> > wrote: > >>> > >>> On Tue, Apr 6, 2010 at 7:53 AM, Jorge Moraleda < > jor...@gm...> > >>> 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; i<5; 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; t<2; 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_insert<long>(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_ios<char, > std::char_traits<char> > >>> > >::init(std::basic_streambuf<char, std::char_traits<char> >*) (in > >>> > /usr/lib/libstdc++.so.6.0.13) > >>> > ==16240== by 0x4ED7DEA: std::basic_stringstream<char, > >>> > std::char_traits<char>, std::allocator<char> > >>> > >::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_insert<long>(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_ios<char, > std::char_traits<char> > >>> > >::init(std::basic_streambuf<char, std::char_traits<char> >*) (in > >>> > /usr/lib/libstdc++.so.6.0.13) > >>> > ==16240== by 0x4ED7DEA: std::basic_stringstream<char, > >>> > std::char_traits<char>, std::allocator<char> > >>> > >::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 reported real multi threading errors? > >>> > If not, how can I tell drd to suppress them? (In my real world > program, > >>> > I > >>> > have thousands of errors in hundreds of contexts, and I am trying to > >>> > find the real ones.) > >>> > If yes, can you help me understand what is wrong? Both threads only > >>> > use local variables. I have been reading about the global object > >>> > "locale" used by streams for localization, but I have read that it is > >>> > protected by a global mutex. > >>> > >>> 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. > > > > The above indeed won't hide races on > > _ZNSs4_Rep20_S_empty_rep_storageE. But I've never claimed that the > > above code would hide these races. And Jorge didn't report any such > > races in his original e-mail. So your reply seems off-topic to me. > > > > Bart. > > > > Dear Bart and Konstantin, > > Thank you very much for your comments. The trick of pre-initializing > the locale object solved a few of my errors, but I still have tons > related to strings and streams. This is another minimal test case: > > #include <pthread.h> > #include <string> > #include <sstream> > > void *threadEntry(void *threadid) > { > long tid; > tid = (long)threadid; > std::string myString; > for (int i = 0; i<5; 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; t<2; 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: 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 0x05134160 size 8 > ==19065== at 0x4EDE984: 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 0x05134178 size 1 > ==19065== at 0x4EDE987: 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== > ==19065== For counts of detected and suppressed errors, rerun with: -v > ==19065== ERROR SUMMARY: 54 errors from 6 contexts (suppressed: 205 from > 142) > > Are all the race conditions in I/O code in libstdc++ bening? > > If so, are there more things that I should initialize in my app before > I start creating threads and/or should I be looking into creating > suppression patterns for drd? Has anyone created them before? Why are > they not enabled by default in drd? > > If not... What should I be reading,doing? Thank you in advance. > > Jorge > |
|
From: Jorge M. <jor...@gm...> - 2010-04-07 01:38:33
|
>
> #include <pthread.h>
> #include <string>
> #include <sstream>
>
> void *threadEntry(void *threadid)
> {
> long tid;
> tid = (long)threadid;
> std::string myString;
> for (int i = 0; i<5; 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; t<2; 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: 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 0x05134160 size 8
> ==19065== at 0x4EDE984: 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 0x05134178 size 1
> ==19065== at 0x4EDE987: 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==
> ==19065== For counts of detected and suppressed errors, rerun with: -v
> ==19065== ERROR SUMMARY: 54 errors from 6 contexts (suppressed: 205 from 142)
>
> Are all the race conditions in I/O code in libstdc++ bening?
>
> If so, are there more things that I should initialize in my app before
> I start creating threads and/or should I be looking into creating
> suppression patterns for drd? Has anyone created them before? Why are
> they not enabled by default in drd?
>
> If not... What should I be reading,doing? Thank you in advance.
>
> Jorge
>
I found the following bug-report against gcc:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518
It seems that the problem is fixed in gcc 4.5. Until it is released, I
added code to my application to not clear empty strings, and it seems
to solve all the these problems. Thank you very much.
Jorge
|
|
From: Stewart S. <st...@fl...> - 2010-04-06 23:26:20
|
On Tue, 06 Apr 2010 22:34:17 +0200, Cyril Scetbon <cyr...@fr...> wrote: > When I start MySQL, InnoDB engine allocate his buffer pool without any > issue. It's not the same when I launch it with Valgrind :( > What can I do to resolve this issue ? How large buffer pool are you trying to allocate? That's likely the issue. Valgrind uses more memory. (have run mysql and now drizzle under valgrind about every day for the past 5 years or something) -- Stewart Smith |
|
From: Jorge M. <jor...@gm...> - 2010-04-06 23:14:59
|
On Tue, Apr 6, 2010 at 3:30 AM, Bart Van Assche <bva...@ac...> wrote:
> On Tue, Apr 6, 2010 at 12:25 PM, Konstantin Serebryany
> <kon...@gm...> wrote:
>>
>>
>> On Tue, Apr 6, 2010 at 2:17 PM, Bart Van Assche <bva...@ac...> wrote:
>>>
>>> On Tue, Apr 6, 2010 at 7:53 AM, Jorge Moraleda <jor...@gm...>
>>> 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; i<5; 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; t<2; 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_insert<long>(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_ios<char, std::char_traits<char>
>>> > >::init(std::basic_streambuf<char, std::char_traits<char> >*) (in
>>> > /usr/lib/libstdc++.so.6.0.13)
>>> > ==16240== by 0x4ED7DEA: std::basic_stringstream<char,
>>> > std::char_traits<char>, std::allocator<char>
>>> > >::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_insert<long>(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_ios<char, std::char_traits<char>
>>> > >::init(std::basic_streambuf<char, std::char_traits<char> >*) (in
>>> > /usr/lib/libstdc++.so.6.0.13)
>>> > ==16240== by 0x4ED7DEA: std::basic_stringstream<char,
>>> > std::char_traits<char>, std::allocator<char>
>>> > >::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 reported real multi threading errors?
>>> > If not, how can I tell drd to suppress them? (In my real world program,
>>> > I
>>> > have thousands of errors in hundreds of contexts, and I am trying to
>>> > find the real ones.)
>>> > If yes, can you help me understand what is wrong? Both threads only
>>> > use local variables. I have been reading about the global object
>>> > "locale" used by streams for localization, but I have read that it is
>>> > protected by a global mutex.
>>>
>>> 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.
>
> The above indeed won't hide races on
> _ZNSs4_Rep20_S_empty_rep_storageE. But I've never claimed that the
> above code would hide these races. And Jorge didn't report any such
> races in his original e-mail. So your reply seems off-topic to me.
>
> Bart.
>
Dear Bart and Konstantin,
Thank you very much for your comments. The trick of pre-initializing
the locale object solved a few of my errors, but I still have tons
related to strings and streams. This is another minimal test case:
#include <pthread.h>
#include <string>
#include <sstream>
void *threadEntry(void *threadid)
{
long tid;
tid = (long)threadid;
std::string myString;
for (int i = 0; i<5; 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; t<2; 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: 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 0x05134160 size 8
==19065== at 0x4EDE984: 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 0x05134178 size 1
==19065== at 0x4EDE987: 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==
==19065== For counts of detected and suppressed errors, rerun with: -v
==19065== ERROR SUMMARY: 54 errors from 6 contexts (suppressed: 205 from 142)
Are all the race conditions in I/O code in libstdc++ bening?
If so, are there more things that I should initialize in my app before
I start creating threads and/or should I be looking into creating
suppression patterns for drd? Has anyone created them before? Why are
they not enabled by default in drd?
If not... What should I be reading,doing? Thank you in advance.
Jorge
|
|
From: John R. <jr...@bi...> - 2010-04-06 20:46:39
|
> When I start MySQL, InnoDB engine allocate his buffer pool without any > issue. It's not the same when I launch it with Valgrind :( > What can I do to resolve this issue ? Post a copy of the error message(s). It is necessary first to identify _which_ error(s). Include the machine architecture (i686, x86_64, etc.) and the operating system. In other words, give a decent bug report. Speculating that you may be running Linux on i686, then _sometimes_ it is possible to obtain an extra 0.8GB of address space by running the i686 version of the application and valgrind on a x86_64 machine. -- |
|
From: Cyril S. <cyr...@fr...> - 2010-04-06 20:34:25
|
Hi, When I start MySQL, InnoDB engine allocate his buffer pool without any issue. It's not the same when I launch it with Valgrind :( What can I do to resolve this issue ? -- Cyril SCETBON |
|
From: Oliver S. <ol...@f-...> - 2010-04-06 15:21:59
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
got a question concerning the use of valgrind.h (which is currently the
only header we use in the unixoid products). We'd like to put the
acknowledgment into the product as given in point 2. of the license
statement in valgrind.h.
Is it appropriate if I add it as follows (assuming version 3.5.0):
valgrind.h, from Valgrind 3.5.0:
Copyright (C) 2000-2009 Julian Seward. All rights reserved.
http://valgrind.org
Should something else be added?
BTW: what would be really useful, is something like a Copyright string
inside a define as literal string. This way it would be easier to
acknowledge you.
Furthermore I'd like to know whether the headers will differ between
platforms, depending on which platform I install them (from the tarball).
Thanks in advance,
- --
Oliver Schneider
Researcher / Developer
FRISK Software International
Thverholti 18
IS-105 Reykjavik
Iceland
phone: +354 540 7400
fax : +354 540 7401
http://www.f-prot.com | http://forum.f-prot.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
iQEcBAEBCAAGBQJLu0vhAAoJEJm+Ui/QYLFP66kH/igxozRrFSFenIos+9rqBj/f
nI0/WjxknkdqyDIYeLUZz9pIMsCIYIJ2yeCaMIJaDkG71aCHS+ODFgEfWRcNyLYN
StSMFBBCPSsEqegFjCgpZW4Tv+tfqs7SDwLnc/nvdx7dMPVztUER95KB1AbHcZyi
cupAxBFRlIElPxE5AXbPg1FvgiUb4yism7ZkJPP9Vx080w1JgujW9aLFcpMZ6hfx
eOAiRrC6tQ8mB6a98p2LTHZGfeHicUIsBSZTw1cFEIke4bYCUE+fAVfNdvmIo1a2
owYb82OWFj03ToFeymL1ZGpegAAoZdqIoSRDjGJY8x00P22TsDprvLsBJMaPXi8=
=IKl8
-----END PGP SIGNATURE-----
|
|
From: Bart V. A. <bva...@ac...> - 2010-04-06 10:30:35
|
On Tue, Apr 6, 2010 at 12:25 PM, Konstantin Serebryany
<kon...@gm...> wrote:
>
>
> On Tue, Apr 6, 2010 at 2:17 PM, Bart Van Assche <bva...@ac...> wrote:
>>
>> On Tue, Apr 6, 2010 at 7:53 AM, Jorge Moraleda <jor...@gm...>
>> 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; i<5; 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; t<2; 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_insert<long>(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_ios<char, std::char_traits<char>
>> > >::init(std::basic_streambuf<char, std::char_traits<char> >*) (in
>> > /usr/lib/libstdc++.so.6.0.13)
>> > ==16240== by 0x4ED7DEA: std::basic_stringstream<char,
>> > std::char_traits<char>, std::allocator<char>
>> > >::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_insert<long>(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_ios<char, std::char_traits<char>
>> > >::init(std::basic_streambuf<char, std::char_traits<char> >*) (in
>> > /usr/lib/libstdc++.so.6.0.13)
>> > ==16240== by 0x4ED7DEA: std::basic_stringstream<char,
>> > std::char_traits<char>, std::allocator<char>
>> > >::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 reported real multi threading errors?
>> > If not, how can I tell drd to suppress them? (In my real world program,
>> > I
>> > have thousands of errors in hundreds of contexts, and I am trying to
>> > find the real ones.)
>> > If yes, can you help me understand what is wrong? Both threads only
>> > use local variables. I have been reading about the global object
>> > "locale" used by streams for localization, but I have read that it is
>> > protected by a global mutex.
>>
>> 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.
The above indeed won't hide races on
_ZNSs4_Rep20_S_empty_rep_storageE. But I've never claimed that the
above code would hide these races. And Jorge didn't report any such
races in his original e-mail. So your reply seems off-topic to me.
Bart.
|
|
From: Konstantin S. <kon...@gm...> - 2010-04-06 10:26:23
|
On Tue, Apr 6, 2010 at 2:17 PM, Bart Van Assche <bva...@ac...> wrote:
> On Tue, Apr 6, 2010 at 7:53 AM, Jorge Moraleda <jor...@gm...>
> 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; i<5; 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; t<2; 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_insert<long>(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_ios<char, std::char_traits<char>
> > >::init(std::basic_streambuf<char, std::char_traits<char> >*) (in
> > /usr/lib/libstdc++.so.6.0.13)
> > ==16240== by 0x4ED7DEA: std::basic_stringstream<char,
> > std::char_traits<char>, std::allocator<char>
> > >::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_insert<long>(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_ios<char, std::char_traits<char>
> > >::init(std::basic_streambuf<char, std::char_traits<char> >*) (in
> > /usr/lib/libstdc++.so.6.0.13)
> > ==16240== by 0x4ED7DEA: std::basic_stringstream<char,
> > std::char_traits<char>, std::allocator<char>
> > >::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 reported real multi threading errors?
> > If not, how can I tell drd to suppress them? (In my real world program, I
> > have thousands of errors in hundreds of contexts, and I am trying to
> > find the real ones.)
> > If yes, can you help me understand what is wrong? Both threads only
> > use local variables. I have been reading about the global object
> > "locale" used by streams for localization, but I have read that it is
> > protected by a global mutex.
>
> 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.
>
>
> ------------------------------------------------------------------------------
> Download Intel® 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
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
|
|
From: Bart V. A. <bva...@ac...> - 2010-04-06 10:17:19
|
On Tue, Apr 6, 2010 at 7:53 AM, Jorge Moraleda <jor...@gm...> 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; i<5; 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; t<2; 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_insert<long>(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_ios<char, std::char_traits<char>
> >::init(std::basic_streambuf<char, std::char_traits<char> >*) (in
> /usr/lib/libstdc++.so.6.0.13)
> ==16240== by 0x4ED7DEA: std::basic_stringstream<char,
> std::char_traits<char>, std::allocator<char>
> >::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_insert<long>(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_ios<char, std::char_traits<char>
> >::init(std::basic_streambuf<char, std::char_traits<char> >*) (in
> /usr/lib/libstdc++.so.6.0.13)
> ==16240== by 0x4ED7DEA: std::basic_stringstream<char,
> std::char_traits<char>, std::allocator<char>
> >::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 reported real multi threading errors?
> If not, how can I tell drd to suppress them? (In my real world program, I
> have thousands of errors in hundreds of contexts, and I am trying to
> find the real ones.)
> If yes, can you help me understand what is wrong? Both threads only
> use local variables. I have been reading about the global object
> "locale" used by streams for localization, but I have read that it is
> protected by a global mutex.
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.
Bart.
|
|
From: Konstantin S. <kon...@gm...> - 2010-04-06 06:57:40
|
This could be the same issue as discussed in http://permalink.gmane.org/gmane.comp.debugging.valgrind/10043 <http://permalink.gmane.org/gmane.comp.debugging.valgrind/10043>--kcc On Tue, Apr 6, 2010 at 9:53 AM, Jorge Moraleda <jor...@gm...>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; i<5; 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; t<2; 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_insert<long>(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_ios<char, std::char_traits<char> > >::init(std::basic_streambuf<char, std::char_traits<char> >*) (in > /usr/lib/libstdc++.so.6.0.13) > ==16240== by 0x4ED7DEA: std::basic_stringstream<char, > std::char_traits<char>, std::allocator<char> > >::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_insert<long>(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_ios<char, std::char_traits<char> > >::init(std::basic_streambuf<char, std::char_traits<char> >*) (in > /usr/lib/libstdc++.so.6.0.13) > ==16240== by 0x4ED7DEA: std::basic_stringstream<char, > std::char_traits<char>, std::allocator<char> > >::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 reported real multi threading errors? > If not, how can I tell drd to suppress them? (In my real world program, I > have thousands of errors in hundreds of contexts, and I am trying to > find the real ones.) > If yes, can you help me understand what is wrong? Both threads only > use local variables. I have been reading about the global object > "locale" used by streams for localization, but I have read that it is > protected by a global mutex. > > By the way, if in the program above I don't include iostream, then drd > reports almost a thousand errors from a hundred contexts! > > Thank you very much! > > Jorge Moraleda > > FYI: I am running ubuntu linux 9.10. This is my system: > > $ valgrind --version > valgrind-3.5.0-Debian > > $ uname -r > 2.6.31-20-generic > > $ gcc -v > Using built-in specs. > Target: x86_64-linux-gnu > Configured with: ../src/configure -v --with-pkgversion='Ubuntu > 4.4.1-4ubuntu9' > --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs > --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr > --enable-shared --enable-multiarch --enable-linker-build-id > --with-system-zlib --libexecdir=/usr/lib --without-included-gettext > --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 > --program-suffix=-4.4 --enable-nls --enable-clocale=gnu > --enable-libstdcxx-debug --enable-objc-gc --disable-werror > --with-arch-32=i486 --with-tune=generic --enable-checking=release > --build=x86_64-linux-gnu --host=x86_64-linux-gnu > --target=x86_64-linux-gnu > Thread model: posix > gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) > > > ------------------------------------------------------------------------------ > Download Intel® 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 > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Jorge M. <jor...@gm...> - 2010-04-06 05:54:02
|
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; i<5; 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; t<2; 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_insert<long>(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_ios<char, std::char_traits<char>
>::init(std::basic_streambuf<char, std::char_traits<char> >*) (in
/usr/lib/libstdc++.so.6.0.13)
==16240== by 0x4ED7DEA: std::basic_stringstream<char,
std::char_traits<char>, std::allocator<char>
>::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_insert<long>(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_ios<char, std::char_traits<char>
>::init(std::basic_streambuf<char, std::char_traits<char> >*) (in
/usr/lib/libstdc++.so.6.0.13)
==16240== by 0x4ED7DEA: std::basic_stringstream<char,
std::char_traits<char>, std::allocator<char>
>::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 reported real multi threading errors?
If not, how can I tell drd to suppress them? (In my real world program, I
have thousands of errors in hundreds of contexts, and I am trying to
find the real ones.)
If yes, can you help me understand what is wrong? Both threads only
use local variables. I have been reading about the global object
"locale" used by streams for localization, but I have read that it is
protected by a global mutex.
By the way, if in the program above I don't include iostream, then drd
reports almost a thousand errors from a hundred contexts!
Thank you very much!
Jorge Moraleda
FYI: I am running ubuntu linux 9.10. This is my system:
$ valgrind --version
valgrind-3.5.0-Debian
$ uname -r
2.6.31-20-generic
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.4.1-4ubuntu9'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--enable-shared --enable-multiarch --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4
--program-suffix=-4.4 --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-objc-gc --disable-werror
--with-arch-32=i486 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)
|
|
From: sam s. <sun...@gm...> - 2010-04-05 22:45:06
|
http://sites.google.com/site/dh56yhsa/ahua1h |
|
From: tom f. <tf...@al...> - 2010-04-05 18:12:26
|
ajit gunge <pea...@ya...> writes: > I am trying to install valgrind on one of my servers which is running > RHEL.It is asking password for me to install.I dotn know what > password I have to give for running valgri nd.Can anyone suggest what > am I doing wrong. You do not need a password to run valgrind. You are probably running a package manager or something that needs superuser access to install it publicly. Use your root password, or install it locally so that you don't need root. Cheers, -tom |
|
From: Indika K. <ind...@gm...> - 2010-04-05 16:02:23
|
Hi,
I'm writing a new tool that will generate a data dependency graph(on
x86 Ubuntu). As the first step, I have modified the 'instrument' function
inside 'none' tool so that you write to a shadow memory for each 'store'
statement as follows.
....
case Ist_Store:{
di = unsafeIRDirty_0_N( 2, "write_sm",VG_(fnptr_to_fnentry)(
&write_sm), mkIRExprVec_2(s->Ist.Store.addr,s->Ist.Store.data) );
addStmtToIRSB( sbOut, IRStmt_Dirty(di) );
addStmtToIRSB( sbOut, s );
break;
}
.....
//where 'write_sm' is as follows.
void write_sm(Addr a, UInt v){
UInt high=a>>16;
UInt low=a & 0x0000ffff;
Spage *p=primary_map[high];
if(!p){
p = VG_(am_shadow_alloc)(sizeof(Spage));
}
p->data[low]=v;
}
//where the structures I use for shadow memory is as follows
typedef
struct {
UInt data[65536];
}
Spage;
static Spage* primary_map[65536];
static Spage default_map;
Int i=0;
static void init_sm (void){
VG_(printf)("Init ");
VG_(printf)( "\n");
for(i=0;i<65536;i++){
default_map.data[i]=0;
}
for(i=0;i<65536;i++){
primary_map[i]=&default_map;
}
}
I get the following error when I try to run this with a small program that
adds two numbers.
user@ubuntu:~$ ./cs510/bin/valgrind --tool=none --run-libc-freeres=no
/home/user/term_project/valgrindnew/valgrindnew/a.out
Init
==22420== Nulgrind, the minimal Valgrind tool
==22420== Copyright (C) 2002-2009, and GNU GPL'd, by Nicholas Nethercote.
==22420== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright
info
==22420== Command: /home/user/term_project/valgrindnew/valgrindnew/a.out
==22420==
vex: priv/host_x86_isel.c:530 (doHelperCall): Assertion
`typeOfIRExpr(env->type_env, args[i]) == Ity_I32' failed.
vex storage: T total 555424 bytes allocated
vex storage: P total 360 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
==22420== at 0x38077EA5: report_and_quit (m_libcassert.c:191)
==22420== by 0x38077F06: panic (m_libcassert.c:275)
==22420== by 0x38077F5D: vgPlain_core_panic_at (m_libcassert.c:280)
==22420== by 0x38077F78: vgPlain_core_panic (m_libcassert.c:285)
==22420== by 0x38017F96: failure_exit (m_translate.c:674)
==22420== by 0x3809B9A3: vex_assert_fail (main_util.c:230)
==22420== by 0x380FD30E: doHelperCall (host_x86_isel.c:530)
==22420== by 0x38103FD5: iselSB_X86 (host_x86_isel.c:3829)
==22420== by 0x3809A380: LibVEX_Translate (main_main.c:598)
==22420== by 0x38015691: vgPlain_translate (m_translate.c:1518)
==22420== by 0x3803C2C1: vgPlain_scheduler (scheduler.c:857)
==22420== by 0x38069AA4: run_a_thread_NORETURN (syswrap-linux.c:94)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==22420== at 0x4000DB9: ??? (in /lib/ld-2.10.1.so)
==22420== by 0x4000856: ??? (in /lib/ld-2.10.1.so)
And I'm unable to figure whats wrong by looking at this. Suggestions on
debugging are highly appreciated.
Thanks.
--
Indika
|
|
From: ajit g. <pea...@ya...> - 2010-04-05 13:42:43
|
Hi All,
I am trying to install valgrind on one of my servers which is running RHEL.It is asking password
for me to install.I dotn know what password I have to give for running valgrind.Can anyone suggest what am I doing wrong.
Thanks and Regards,
Ajit
|
|
From: tom f. <tf...@al...> - 2010-04-04 18:37:21
|
Massif is saying that I have allocated a (quite large) std::vector inside my `main' function [1]. The vector template is not used at all in the file which declares the main function. Is this vector coming from a static initializer, then? How can I identify the location of the allocation? This is with valgrind-3.5.0 on a debian stable, x86_64 installation. -tom [1] 20 2,008,492,212 134,862,424 134,564,847 297,577 0 99.78% (134,564,847B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc. ->49.76% (67,108,864B) 0x4EA992E: std::vector<unsigned char, std::allocator<unsigned char> >::_M_fill_insert(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, unsigned long, unsigned char const&) (new_allocator.h:92) | ->49.76% (67,108,864B) 0x1989D998: ??? | | ->49.76% (67,108,864B) 0x1980D935: ??? | | ->49.76% (67,108,864B) 0x19900A89: ??? | | ->49.76% (67,108,864B) 0x19910CE4: ??? | | ->49.76% (67,108,864B) 0x197D9DF1: ??? | | ->49.76% (67,108,864B) 0x400D384: _dl_catch_error (in /lib/ld-2.7.so) | | ->49.76% (67,108,864B) 0x4011119: _dl_open (in /lib/ld-2.7.so) | | ->49.76% (67,108,864B) 0xF720FB9: dlopen_doit (in /lib/libdl-2.7.so) | | ->49.76% (67,108,864B) 0x400D384: _dl_catch_error (in /lib/ld-2.7.so) | | ->49.76% (67,108,864B) 0xF72136A: _dlerror_run (in /lib/libdl-2.7.so) | | ->49.76% (67,108,864B) 0xF720F1F: dlopen@@GLIBC_2.2.5 (in /lib/libdl-2.7.so) | | ->49.76% (67,108,864B) 0x50CC2E7: PluginManager::PluginOpen(std::string const&) (PluginManager.C:1486) | | ->49.76% (67,108,864B) 0x50CC5CC: PluginManager::LoadSinglePlugin(int) (PluginManager.C:982) | | ->49.76% (67,108,864B) 0x50CC2A4: PluginManager::PluginAvailable(std::string const&) (PluginManager.C:197) | | ->49.76% (67,108,864B) 0x4E601D9: RPCExecutor<PreparePlotRPC>::Execute(PreparePlotRPC*) (Executors.h:414) | | ->49.76% (67,108,864B) 0x68764C6: Subject::Notify() (Subject.C:188) | | ->49.76% (67,108,864B) 0x67A1CCB: AttributeSubject::Notify() (AttributeSubject.C:99) | | ->49.76% (67,108,864B) 0xA2CFBE0: MPIXfer::Process() (MPIXfer.C:331) | | ->49.76% (67,108,864B) 0x4E5F3EF: Engine::PAR_EventLoop() (Engine.C:1462) | | ->49.76% (67,108,864B) 0x40BD24: main (main.C:316) |
|
From: Junchang W. <jun...@gm...> - 2010-04-04 04:30:16
|
Hi list, Is there anybody who can give ben a exact answer? Thanks. --Junchang ---------- Forwarded message ---------- From: Junchang Wang <jun...@gm...> Date: Sat, Apr 3, 2010 at 8:05 PM Subject: Re: valgrind problems To: ben...@ya... Hi ben, Xeon 5410 was used in my previous work. If I specified the type of L2 cache, valgrind worked fine. What's your hardware configuration? I suggest posting your mail on Val...@li... for more help. --Junchang On Fri, Apr 2, 2010 at 9:56 PM, <ben...@ya...> wrote: > I have read your message about the cache L2. I'm having the same problem > now when exeuting my code with valgrind: > --9181-- warning: Unknown Intel cache config value (0x78), ignoring > --9181-- warning: L2 cache not installed, ignore L2 results. > and when i specified my cache L2, i obtain this message: > valgrind: failed to start tool 'cachgrind--L2=1048576,16,64' for platform > 'x86-linux': No such file or directory > > Please can you tell me how could you resolve this problem, it 'is really > very important for me and i haven't enough time. > Thanks a lot in advance. > This is my hardware configuration: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Pentium(R) Dual CPU E2180 @ 2.00GHz stepping : 13 cpu MHz : 1800.000 cache size : 1024 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 4020.16 clflush size : 64 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Pentium(R) Dual CPU E2180 @ 2.00GHz stepping : 13 cpu MHz : 1800.000 cache size : 1024 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 4020.30 clflush size : 64 In addition : size:1024k, associativity:4, size line: 64 Thanks a lot for your answer. |
|
From: Milian W. <ma...@mi...> - 2010-04-02 22:43:43
|
Hey List! I wrote a GUI for visualizing Massif log data, and thought it would be a good idea to announce it here: http://kde-apps.org/content/show.php/Massif+Visualizer?content=122409 http://gitorious.org/massif-visualizer Here the description from the project website: ~~~~ Massif Visualizer is a tool that - *who would guess that* - visualizes massif data. You run your application in Valgrind with `--tool=massif` and the open the generated `massif.out.%pid` in this application. You can also compress the log with Gzip or Bzip2 and open it transparently with the visualizer. The application consists of three parts: # The Overview Chart The first thing you will notice is a nice chart that displays the same as e.g. `ms_print` does in Ascii-Art: total memory consumption over time. What Massif-Visualizer goes further is by additionally showing the top ten most cost-intensive locations in your code as a stacked graph below the total cost. The graph also reacts on user-interaction. This view you can use for - checking whether your application has memory leaks - finding too expensive peaks - finding locations that significantly contribute to the overall memory consumption of your application # The Snapshot Data Tree Directly next to the above chart, you will see a tree with all of the massif data. The tree items are colored depending on their cost, with red opaque being the most interesting (peak) elements. Green/transparent items are negligible and do not add significant cost to your application. You can also search the tree and when you select something in it, the snapshot gets highlighted in the overview chart and the call graph gets updated. # The Call Graph for Detailed Snapshots Massif generates a few detailed snapshots that essentially make up the tree. If you want to get an overview in a more comfortable way than the simple tree view, switch over to the detailed snapshot tab and see the tree visualized as a call graph. Zoom in, zoom out, use the birds eye view and see what contributes to a given snapshot. Note that function calls with the same memory cost are grouped to easily find the interesting parts. ~~~ I'd appreciate any kind of feedback, esp. in regard to whether that tool helps or whether my choices here and there are good. I think mostly of the (simple) algorithm that gets the interesting data points in the stacked chart below the total mem consumption. Currently I decided to select the first item that forks in the Massif data tree. Anyways, you should probably use it and tell me whether the graphs and charts are OK or could be done better. It's depending on kdelibs from 4.X (tested with 4.3 and above). Furthermore there is currently a compile and runtime dependency on KGraphViewer from Trunk: http://extragear.kde.org/apps/kgraphviewer/ I plan to make the latter optional. Have a nice holiday where applicable or at least a nice weekend. To the valgrind devels out there: Thanks for the amazing work, I love it! -- Milian Wolff ma...@mi... http://milianw.de |
|
From: No I. <the...@gm...> - 2010-04-02 07:53:48
|
A cursory search through the source code indicates that MEMPOOL_ALLOC calls new_block, which increments cmalloc_n_mallocs, but there is no corresponding change to cmalloc_n_frees in MEMPOOL_FREE. Here's a patch that increments it at the very end of MEMPOOL_FREE. This gives me the behavior I expect. |
|
From: No I. <the...@gm...> - 2010-04-02 07:29:06
|
My usage of VALGRIND_MEMPOOL_FREE doesn't seem to be reflected in the heap summary on version 3.5.0, though it doesn't complain about leaks. Is this the expected behavior? Here is my uname and a program that demonstrates my issue: http://pastebin.com/yw5m09j6 |
|
From: Aswin c. <luc...@gm...> - 2010-04-01 12:32:19
|
Hi All,
I Created a output file foe a executable using
tool valgrind --tool=callgrind ./myexecutable
it is giving library functions also in the ouput i just want to
detect that library functions.Because my objective is see the call graph in
kcachegrind with only functions of my source file. so please help me in
doing this.
Thank
you
|