|
From: Madhan S. <mad...@gm...> - 2008-12-24 13:32:21
|
Hello, I am using Valgrind-3.3.1, to test my multi-threaded application. I am using the following options. --log-file=/scratch/valg/valgrind_agent.log%p --leak-check=full --leak-resolution=high --show-reachable=yes --track-fds=yes --workaround-gcc296-bugs=yes --error-limit=no --num-callers=60 --run-libc-freeres=no -v --tool=memcheck The log file seems to have output mixed up from multiple pids. For example here is a sample. The errors from processes 15155 and 15151 are appearing at the same time and making the error message unusable. ==15155== ==15151== by 0x805EE02: agent(int, unsigned char**) (Agent.cpp:153) ==15151== by 0x8057790: main (AgentMain.cpp:125) ==15155== ====15151== ==15151=14 bytes in 112 bytes in 1 blocks are still reachable in loss record 272 of 4,611===15151== A major portion of the log file is clean, but after a certain time, everything is mixed up. Will the xml option solve this issue. Thanks, Madhan. |
|
From: Bart V. A. <bar...@gm...> - 2008-12-24 15:06:05
|
On Wed, Dec 24, 2008 at 2:31 PM, Madhan Sadasivam <mad...@gm...> wrote: > > Hello, > > I am using Valgrind-3.3.1, to test my multi-threaded application. > I am using the following options. > > --log-file=/scratch/valg/valgrind_agent.log%p > --leak-check=full > --leak-resolution=high > --show-reachable=yes > --track-fds=yes > --workaround-gcc296-bugs=yes > --error-limit=no > --num-callers=60 > --run-libc-freeres=no > -v > --tool=memcheck > > > The log file seems to have output mixed up from multiple pids. > For example here is a sample. The errors from processes 15155 and 15151 > are appearing at the same time and making the error message unusable. > > > ==15155== ==15151== by 0x805EE02: agent(int, unsigned char**) (Agent.cpp:153) > ==15151== by 0x8057790: main (AgentMain.cpp:125) > ==15155== > ====15151== > ==15151=14 bytes in 112 bytes in 1 blocks are still reachable in loss record 272 of 4,611===15151== > > > A major portion of the log file is clean, but after a certain time, everything > is mixed up. Will the xml option solve this issue. I don't know whether the XML option will solve this issue, but if I remember correctly, this issue was solved in r7875. Can you please test whether the above issue is solved in the trunk version of Valgrind ? You can find instructions for downloading and compiling the trunk on Valgrind's web page. Bart. |
|
From: Nicholas N. <nj...@cs...> - 2008-12-24 22:18:00
|
On Wed, 24 Dec 2008, Bart Van Assche wrote: >> The log file seems to have output mixed up from multiple pids. >> For example here is a sample. The errors from processes 15155 and 15151 >> are appearing at the same time and making the error message unusable. >> >> >> ==15155== ==15151== by 0x805EE02: agent(int, unsigned char**) (Agent.cpp:153) >> ==15151== by 0x8057790: main (AgentMain.cpp:125) >> ==15155== >> ====15151== >> ==15151=14 bytes in 112 bytes in 1 blocks are still reachable in loss record 272 of 4,611===15151== > > I don't know whether the XML option will solve this issue, but if I > remember correctly, this issue was solved in r7875. Can you please > test whether the above issue is solved in the trunk version of > Valgrind ? You can find instructions for downloading and compiling the > trunk on Valgrind's web page. I doubt that r7875 solves it -- without interprocess communication or file locking, if two processes are trying to write to the same file you'll get a jumble, no? Nick |
|
From: Julian S. <js...@ac...> - 2008-12-24 22:41:24
|
> >> ==15155== ==15151== by 0x805EE02: agent(int, unsigned char**) > >> (Agent.cpp:153) ==15151== by 0x8057790: main (AgentMain.cpp:125) > >> ==15155== > >> ====15151== > >> ==15151=14 bytes in 112 bytes in 1 blocks are still reachable in loss > >> record 272 of 4,611===15151== I think --child-silent-after-fork=yes (which basically disables all output in a child between fork and exec) might help. Can't remember if 3.3.x supports this, though. J |
|
From: Bart V. A. <bar...@gm...> - 2008-12-25 07:23:31
|
On Wed, Dec 24, 2008 at 11:17 PM, Nicholas Nethercote <nj...@cs...> wrote: > On Wed, 24 Dec 2008, Bart Van Assche wrote: > >>> The log file seems to have output mixed up from multiple pids. >>> For example here is a sample. The errors from processes 15155 and 15151 >>> are appearing at the same time and making the error message unusable. >>> >>> >>> ==15155== ==15151== by 0x805EE02: agent(int, unsigned char**) >>> (Agent.cpp:153) >>> ==15151== by 0x8057790: main (AgentMain.cpp:125) >>> ==15155== >>> ====15151== >>> ==15151=14 bytes in 112 bytes in 1 blocks are still reachable in loss >>> record 272 of 4,611===15151== >> >> I don't know whether the XML option will solve this issue, but if I >> remember correctly, this issue was solved in r7875. Can you please >> test whether the above issue is solved in the trunk version of >> Valgrind ? You can find instructions for downloading and compiling the >> trunk on Valgrind's web page. > > I doubt that r7875 solves it -- without interprocess communication or file > locking, if two processes are trying to write to the same file you'll get a > jumble, no? As far as I can see the original question is about a multithreaded application, not about multiple processes. r7875 buffers Valgrind's message output per line such that output written by different threads does not get mixed up. Bart. |
|
From: Madhan S. <mad...@gm...> - 2008-12-25 13:54:42
|
Thanks for the inputs. Child processes are involved and the errors from children are also important. I guess -child-silent-after-fork=yes might suppress everything from the child. I will give r7875 a try and will let you know. Merry Christmas and happy holidays to all. Thanks, Madhan. On Thu, Dec 25, 2008 at 12:53 PM, Bart Van Assche <bar...@gm...>wrote: > On Wed, Dec 24, 2008 at 11:17 PM, Nicholas Nethercote > <nj...@cs...> wrote: > > On Wed, 24 Dec 2008, Bart Van Assche wrote: > > > >>> The log file seems to have output mixed up from multiple pids. > >>> For example here is a sample. The errors from processes 15155 and 15151 > >>> are appearing at the same time and making the error message unusable. > >>> > >>> > >>> ==15155== ==15151== by 0x805EE02: agent(int, unsigned char**) > >>> (Agent.cpp:153) > >>> ==15151== by 0x8057790: main (AgentMain.cpp:125) > >>> ==15155== > >>> ====15151== > >>> ==15151=14 bytes in 112 bytes in 1 blocks are still reachable in loss > >>> record 272 of 4,611===15151== > >> > >> I don't know whether the XML option will solve this issue, but if I > >> remember correctly, this issue was solved in r7875. Can you please > >> test whether the above issue is solved in the trunk version of > >> Valgrind ? You can find instructions for downloading and compiling the > >> trunk on Valgrind's web page. > > > > I doubt that r7875 solves it -- without interprocess communication or > file > > locking, if two processes are trying to write to the same file you'll get > a > > jumble, no? > > As far as I can see the original question is about a multithreaded > application, not about multiple processes. r7875 buffers Valgrind's > message output per line such that output written by different threads > does not get mixed up. > > Bart. > |
|
From: Bart V. A. <bar...@gm...> - 2009-01-02 12:00:24
|
On Fri, Jan 2, 2009 at 12:44 PM, Madhan Sadasivam <mad...@gm...> wrote: > I sit behind a firewall and cannot access the svn repository directly. > I tried the checkout from a windows machine and after bringing it to Linux > the build fails. > > Is there a http/ftp way of getting the latest dev version of Valgrind from > valgrind svn. The 3.4.0 RC1 is very close to the latest development version, and you can find it here: http://www.valgrind.org/downloads/valgrind-3.4.0.RC1.tar.bz2 Bart. |
|
From: Madhan S. <mad...@gm...> - 2009-01-02 12:16:15
|
I sit behind a firewall and cannot access the svn repository directly. I tried the checkout from a windows machine and after bringing it to Linux the build fails. Is there a http/ftp way of getting the latest dev version of Valgrind from valgrind svn. Thanks, Madhan. On Thu, Dec 25, 2008 at 7:24 PM, Madhan Sadasivam <mad...@gm...>wrote: > Thanks for the inputs. > Child processes are involved and the errors from children are also > important. > I guess -child-silent-after-fork=yes might suppress everything from the > child. > > I will give r7875 a try and will let you know. > > Merry Christmas and happy holidays to all. > > Thanks, > Madhan. > > > On Thu, Dec 25, 2008 at 12:53 PM, Bart Van Assche < > bar...@gm...> wrote: > >> On Wed, Dec 24, 2008 at 11:17 PM, Nicholas Nethercote >> <nj...@cs...> wrote: >> > On Wed, 24 Dec 2008, Bart Van Assche wrote: >> > >> >>> The log file seems to have output mixed up from multiple pids. >> >>> For example here is a sample. The errors from processes 15155 and >> 15151 >> >>> are appearing at the same time and making the error message unusable. >> >>> >> >>> >> >>> ==15155== ==15151== by 0x805EE02: agent(int, unsigned char**) >> >>> (Agent.cpp:153) >> >>> ==15151== by 0x8057790: main (AgentMain.cpp:125) >> >>> ==15155== >> >>> ====15151== >> >>> ==15151=14 bytes in 112 bytes in 1 blocks are still reachable in loss >> >>> record 272 of 4,611===15151== >> >> >> >> I don't know whether the XML option will solve this issue, but if I >> >> remember correctly, this issue was solved in r7875. Can you please >> >> test whether the above issue is solved in the trunk version of >> >> Valgrind ? You can find instructions for downloading and compiling the >> >> trunk on Valgrind's web page. >> > >> > I doubt that r7875 solves it -- without interprocess communication or >> file >> > locking, if two processes are trying to write to the same file you'll >> get a >> > jumble, no? >> >> As far as I can see the original question is about a multithreaded >> application, not about multiple processes. r7875 buffers Valgrind's >> message output per line such that output written by different threads >> does not get mixed up. >> >> Bart. >> > > |
|
From: Robert W. <rj...@du...> - 2009-01-02 14:23:02
|
What's the failure you see? Did you run autogen.sh first? Regards, Robert. On Jan 2, 2009, at 3:44 AM, "Madhan Sadasivam" <mad...@gm...> wrote: > I sit behind a firewall and cannot access the svn repository directly. > I tried the checkout from a windows machine and after bringing it to > Linux the build fails. > > Is there a http/ftp way of getting the latest dev version of > Valgrind from valgrind svn. > > Thanks, > Madhan. > > > On Thu, Dec 25, 2008 at 7:24 PM, Madhan Sadasivam <mad...@gm... > > wrote: > Thanks for the inputs. > Child processes are involved and the errors from children are also > important. > I guess -child-silent-after-fork=yes might suppress everything from > the child. > > I will give r7875 a try and will let you know. > > Merry Christmas and happy holidays to all. > > Thanks, > Madhan. > > > On Thu, Dec 25, 2008 at 12:53 PM, Bart Van Assche <bar...@gm... > > wrote: > On Wed, Dec 24, 2008 at 11:17 PM, Nicholas Nethercote > <nj...@cs...> wrote: > > On Wed, 24 Dec 2008, Bart Van Assche wrote: > > > >>> The log file seems to have output mixed up from multiple pids. > >>> For example here is a sample. The errors from processes 15155 > and 15151 > >>> are appearing at the same time and making the error message > unusable. > >>> > >>> > >>> ==15155== ==15151== by 0x805EE02: agent(int, unsigned char**) > >>> (Agent.cpp:153) > >>> ==15151== by 0x8057790: main (AgentMain.cpp:125) > >>> ==15155== > >>> ====15151== > >>> ==15151=14 bytes in 112 bytes in 1 blocks are still reachable in > loss > >>> record 272 of 4,611===15151== > >> > >> I don't know whether the XML option will solve this issue, but if I > >> remember correctly, this issue was solved in r7875. Can you please > >> test whether the above issue is solved in the trunk version of > >> Valgrind ? You can find instructions for downloading and > compiling the > >> trunk on Valgrind's web page. > > > > I doubt that r7875 solves it -- without interprocess communication > or file > > locking, if two processes are trying to write to the same file > you'll get a > > jumble, no? > > As far as I can see the original question is about a multithreaded > application, not about multiple processes. r7875 buffers Valgrind's > message output per line such that output written by different threads > does not get mixed up. > > Bart. > > > --- > --- > --- > --------------------------------------------------------------------- > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Madhan S. <mad...@gm...> - 2009-01-07 13:38:21
|
Thanks Bart, I tried the released 3.4.0 version. The problem is still seen. Here are some samples: 1) Mixed up lines ==20950== by 0x74F8FF0: ModUpdat==21135== definitely lost: 27,799 bytes in 187 blocks. ==21135== indirectl==20950== by 0x74E1C56: ChooseEnc==21135== possibly lost: 642,605 bytes in 25,850 blocks. 2) One stack frame split into 2 lines and the function name is lost. ==20950== by 0x9702407B: ??? nst*, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.3) Options used: --log-file=/scratch/work/valgrind_check.pid%p --leak-check=full --leak-resolution=high --undef-value-errors=yes --track-fds=yes --workaround-gcc296-bugs=yes --error-limit=no --num-callers=60 --run-libc-freeres=no -v --tool=memcheck Thanks, Madhan. On Fri, Jan 2, 2009 at 5:22 PM, Bart Van Assche <bar...@gm...>wrote: > On Fri, Jan 2, 2009 at 12:44 PM, Madhan Sadasivam <mad...@gm...> > wrote: > > I sit behind a firewall and cannot access the svn repository directly. > > I tried the checkout from a windows machine and after bringing it to > Linux > > the build fails. > > > > Is there a http/ftp way of getting the latest dev version of Valgrind > from > > valgrind svn. > > The 3.4.0 RC1 is very close to the latest development version, and you > can find it here: > http://www.valgrind.org/downloads/valgrind-3.4.0.RC1.tar.bz2 > > Bart. > |
|
From: Julian S. <js...@ac...> - 2009-01-07 15:01:48
|
> Options used: > --log-file=/scratch/work/valgrind_check.pid%p > --leak-check=full > --leak-resolution=high > --undef-value-errors=yes > --track-fds=yes > --workaround-gcc296-bugs=yes > --error-limit=no > --num-callers=60 > --run-libc-freeres=no > -v > --tool=memcheck You need --child-silent-after-fork=yes. J |
|
From: Madhan S. <mad...@gm...> - 2009-01-11 19:25:56
|
Thanks Julian, I tried all of my tests again and there are no mixed up lines. I should have listened to you the first time. Let me make sure I understand it clearly. You have mentioned that, --child-silent-after-fork option suppresses all output between a fork and exec. The %p specifier in the --log-file option, I thought is used to give every pid its own file and to avoid the jumbling up in log files. So fork does not create a new log file even with %p. Thanks, Madhan. On Wed, Jan 7, 2009 at 8:17 PM, Julian Seward <js...@ac...> wrote: > > > Options used: > > --log-file=/scratch/work/valgrind_check.pid%p > > --leak-check=full > > --leak-resolution=high > > --undef-value-errors=yes > > --track-fds=yes > > --workaround-gcc296-bugs=yes > > --error-limit=no > > --num-callers=60 > > --run-libc-freeres=no > > -v > > --tool=memcheck > > You need --child-silent-after-fork=yes. > > J > |
|
From: Julian S. <js...@ac...> - 2009-01-11 19:30:44
|
> Let me make sure I understand it clearly. You have mentioned that, > --child-silent-after-fork option suppresses all output between a fork and > exec. The %p specifier in the --log-file option, I thought is used to give > every pid its own file and to avoid the jumbling up in log files. So fork > does not create a new log file even with %p. The logfile is created at exec time, not when fork happens. So that means that in between the fork and the exec, the child process is writing to the same file as the parent. --child-silent-after-fork=yes makes the child be quiet exactly in the time between fork and exec. After the child does exec, it creates a new log file with its own PID and so everything goes back to normal after that. J |
|
From: Madhan S. <mad...@gm...> - 2009-01-12 05:58:25
|
Thanks Julian. That clearly answers my question. In my application I have seen that its always a fork and exec, with negligible code in between them. Let me go back and check if there is a functionality with only a fork and no exec. Thanks again, Madhan. On Mon, Jan 12, 2009 at 12:46 AM, Julian Seward <js...@ac...> wrote: > > > Let me make sure I understand it clearly. You have mentioned that, > > --child-silent-after-fork option suppresses all output between a fork and > > exec. The %p specifier in the --log-file option, I thought is used to > give > > every pid its own file and to avoid the jumbling up in log files. So fork > > does not create a new log file even with %p. > > The logfile is created at exec time, not when fork happens. So that means > that in between the fork and the exec, the child process is writing to the > same file as the parent. --child-silent-after-fork=yes makes the child be > quiet exactly in the time between fork and exec. After the child does > exec, it creates a new log file with its own PID and so everything goes > back to normal after that. > > J > |