|
From: Manish M. <mma...@sp...> - 2005-10-02 20:38:52
|
Hello All,
I ran mysql tests under Valgrind with XML output. Looks like after each
test Valgrind completes the </valgrindoutput> and then for the next test
it just carries on without starting the <valgrindoutput> starting tag,
although this should not happen, the </valgrindoutput> tag should be
completed in the end. Something weired. Here is some part of the xml
output
<?xml version="1.0"?>
<valgrindoutput>
<protocolversion>1</protocolversion>
<preamble>
<line>Memcheck, a memory error detector.</line>
<line>Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et
al.</line>
<line>Using LibVEX rev 1367, a library for dynamic binary
translation.</line>
<line>Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.</line>
<line>Using valgrind-3.0.1, a dynamic binary instrumentation
framework.</line>
<line>Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et
al.</line>
</preamble>
<pid>21021</pid>
<ppid>23845</ppid>
<tool>memcheck</tool>
<args>
<vargv>
<exe>valgrind</exe>
<arg>--xml=yes</arg>
<arg>--demangle=yes</arg>
<arg>--verbose</arg>
<arg>--show-below-main=yes</arg>
</vargv>
<argv>
<exe>/bin/sh</exe>
<arg>./mysql-test-run.sh</arg>
<arg>--force</arg>
<arg>--skip-bdb</arg>
<arg>--ps-protocol</arg>
<arg>|</arg>
<arg>tee</arg>
<arg>/tmp/valgrind-mysqltest.xml</arg>
</argv>
</args>
<status> <state>RUNNING</state> <time>2005-09-29 16:33:00.065</time>
</status>
./mysql-test-run.sh: line 31: ulimit: open files: cannot modify limit:
Operation not permitted
<errorcounts>
</errorcounts>
<status> <state>FINISHED</state> <time>2005-09-29 16:33:02.350</time>
</status>
<suppcounts>
<pair> <count>3</count> <name>index-not-intercepted-early-enough-
HACK-3</name> </pair>
<pair> <count>21</count> <name>Ugly strchr error
in /lib/ld-2.3.3.so</name> </pair>
</suppcounts>
</valgrindoutput> <------------------- [ VALGRIND ENDED THE FILE
HERE, ]
<error> <-------- [FOR THE NEXT TEST IT CARRIED ON WITH <error>
TAG]
<unique>0x18</unique>
<tid>1</tid>
<kind>InvalidRead</kind>
<what>Invalid read of size 4</what>
<stack>
<frame>
<ip>0x1B940D57</ip>
<obj>/lib/tls/libc-2.3.3.so</obj>
<fn>sigprocmask</fn>
</frame>
<frame>
<ip>0x8068B7D</ip>
<obj>/bin/bash</obj>
</frame>
<frame>
|
|
From: Manish M. <mma...@sp...> - 2005-10-03 16:59:33
|
Hello All, Can anyone give me some insight on how the XML output is weird. I have explained the case below. On Fri, 2005-09-30 at 10:23 -0700, Manish Marathe wrote: > Hello All, > > I ran mysql tests under Valgrind with XML output. Looks like after each > test Valgrind completes the </valgrindoutput> and then for the next test > it just carries on without starting the <valgrindoutput> starting tag, > although this should not happen, the </valgrindoutput> tag should be > completed in the end. Something weired. Here is some part of the xml > output > > <?xml version="1.0"?> > > <valgrindoutput> > > <protocolversion>1</protocolversion> > > <preamble> > <line>Memcheck, a memory error detector.</line> > <line>Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et > al.</line> > <line>Using LibVEX rev 1367, a library for dynamic binary > translation.</line> > <line>Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.</line> > <line>Using valgrind-3.0.1, a dynamic binary instrumentation > framework.</line> > <line>Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et > al.</line> > </preamble> > > <pid>21021</pid> > <ppid>23845</ppid> > <tool>memcheck</tool> > > <args> > <vargv> > <exe>valgrind</exe> > <arg>--xml=yes</arg> > <arg>--demangle=yes</arg> > <arg>--verbose</arg> > <arg>--show-below-main=yes</arg> > </vargv> > <argv> > <exe>/bin/sh</exe> > <arg>./mysql-test-run.sh</arg> > <arg>--force</arg> > <arg>--skip-bdb</arg> > <arg>--ps-protocol</arg> > <arg>|</arg> > <arg>tee</arg> > <arg>/tmp/valgrind-mysqltest.xml</arg> > </argv> > </args> > > <status> <state>RUNNING</state> <time>2005-09-29 16:33:00.065</time> > </status> > > ./mysql-test-run.sh: line 31: ulimit: open files: cannot modify limit: > Operation not permitted > > <errorcounts> > </errorcounts> > > <status> <state>FINISHED</state> <time>2005-09-29 16:33:02.350</time> > </status> > > <suppcounts> > <pair> <count>3</count> <name>index-not-intercepted-early-enough- > HACK-3</name> </pair> > <pair> <count>21</count> <name>Ugly strchr error > in /lib/ld-2.3.3.so</name> </pair> > </suppcounts> > > </valgrindoutput> <------------------- [ VALGRIND ENDED THE FILE > HERE, ] > > <error> <-------- [FOR THE NEXT TEST IT CARRIED ON WITH <error> > TAG] > > <unique>0x18</unique> > <tid>1</tid> > <kind>InvalidRead</kind> > <what>Invalid read of size 4</what> > <stack> > <frame> > <ip>0x1B940D57</ip> > <obj>/lib/tls/libc-2.3.3.so</obj> > <fn>sigprocmask</fn> > </frame> > <frame> > <ip>0x8068B7D</ip> > <obj>/bin/bash</obj> > </frame> > <frame> > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicholas N. <nj...@cs...> - 2005-10-03 19:06:12
|
On Mon, 3 Oct 2005, Manish Marathe wrote: > Can anyone give me some insight on how the XML output is weird. I have > explained the case below. You could raise a bug in Bugzilla, and hopefully someone will get a chance to look at it soon. But note that there are 93 open bugs in Bugzilla, and we do not have the resources to consider them all. It might be quicker to try and debug it yourself. If you do file a bug, it would be helpful if you gave more information about how Valgrind gets executed within this test framework. Nick |
|
From: Olly B. <ol...@su...> - 2005-10-03 19:55:42
|
On 2005-10-03, Nicholas Nethercote <nj...@cs...> wrote:
> If you do file a bug, it would be helpful if you gave more information
> about how Valgrind gets executed within this test framework.
I bet the problem is that they're calling VALGRIND_DO_LEAK_CHECK more
than once in their testsuite and this writes out </valgrindoutput>
each time.
As support for this theory, I just tried --xml=yes on my own testharness
and I get multiple occurences of "</valgrindoutput>".
Cheers,
Olly
|
|
From: Manish M. <mma...@sp...> - 2005-10-03 20:21:38
|
On Mon, 2005-10-03 at 19:51 +0000, Olly Betts wrote: > On 2005-10-03, Nicholas Nethercote <nj...@cs...> wrote: > > If you do file a bug, it would be helpful if you gave more information > > about how Valgrind gets executed within this test framework. > > I bet the problem is that they're calling VALGRIND_DO_LEAK_CHECK more > than once in their testsuite and this writes out </valgrindoutput> > each time. What do you mean by their testsuite as the testsuite of MySQL cannot call VALGRIND_DO_LEAK_CHECK more than once. So it means after each test VALGRIND_DO_LEAK_CHECK is getting called which writes </valgrindoutput>. Does this mean its a potential bug in Valgrind or is something that we can readily do about it. Thanks for trying it out, really appreciate that. > > As support for this theory, I just tried --xml=yes on my own testharness > and I get multiple occurences of "</valgrindoutput>". > > Cheers, > Olly > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Olly B. <ol...@su...> - 2005-10-03 22:57:55
|
On 2005-10-03, Manish Marathe <mma...@sp...> wrote:
> On Mon, 2005-10-03 at 19:51 +0000, Olly Betts wrote:
>> I bet the problem is that they're calling VALGRIND_DO_LEAK_CHECK more
>> than once in their testsuite and this writes out </valgrindoutput>
>> each time.
>
> What do you mean by their testsuite as the testsuite of MySQL cannot
> call VALGRIND_DO_LEAK_CHECK more than once.
I meant "their" == "MySQL's".
VALGRIND_DO_LEAK_CHECK is a client request, so you can call it whenever
you like from the code being "valgrinded" (or is it "valground"?)
> So it means after each test VALGRIND_DO_LEAK_CHECK is getting called
> which writes </valgrindoutput>.
That was my supposition, but it looks like I was wrong (see my reply to
Julian).
> Does this mean its a potential bug in Valgrind or is something that we
> can readily do about it.
Well, it would have been a valgrind bug...
Cheers,
Olly
|
|
From: Julian S. <js...@ac...> - 2005-10-03 20:28:34
|
On Monday 03 October 2005 20:51, Olly Betts wrote: > On 2005-10-03, Nicholas Nethercote <nj...@cs...> wrote: > > If you do file a bug, it would be helpful if you gave more information > > about how Valgrind gets executed within this test framework. > > I bet the problem is that they're calling VALGRIND_DO_LEAK_CHECK more > than once in their testsuite and this writes out </valgrindoutput> > each time. My alternative bet is that this is something to do with the last thread to exit not being the one that the test driver is wait()ing for. Manish, can we have some details of the test harness and of the thread structure of the tests? > As support for this theory, I just tried --xml=yes on my own testharness > and I get multiple occurences of "</valgrindoutput>". Urk. Can you narrow this down to a simple test case? Do the test cases do fork() ? J |
|
From: Manish M. <mma...@sp...> - 2005-10-03 21:03:58
|
On Mon, 2005-10-03 at 21:30 +0100, Julian Seward wrote: > My alternative bet is that this is something to do with the > last thread to exit not being the one that the test driver is > wait()ing for. Manish, can we have some details of the > test harness and of the thread structure of the tests? > > Urk. Can you narrow this down to a simple test case? Do the > test cases do fork() ? > Thanks Julian for pointing me to that direction and although I quickly glanced at the structure of script file which loops through the test suite, not to mention its too complicated, but I don't suppose the test cases use fork and if they don't then I believe Valgrind considers the next test case as a new process ? Well I do component builds of many components on different platforms. So if it would have been just MySQL case then it could have been possible to actually make the test cases forked but I will be using Valgrind to monitor test case execution for all components and it may not be possible to comprehend and then change the thread structure of the test suite all components. Is there a quick way I can modify in Valgrind source and build it again for XML output which would solve this problem ? > J > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Olly B. <ol...@su...> - 2005-10-03 22:51:20
|
On 2005-10-03, Julian Seward <js...@ac...> wrote:
> On Monday 03 October 2005 20:51, Olly Betts wrote:
>> As support for this theory, I just tried --xml=yes on my own testharness
>> and I get multiple occurences of "</valgrindoutput>".
>
> Urk. Can you narrow this down to a simple test case? Do the
> test cases do fork() ?
I've just realised there is a fork involved, because I was running
valgrind on the libtool wrapper script, not the compiled code.
I'm struggling to produce a simple test case right now, and don't have
a lot of spare time to work on it I'm afraid.
Julian: If you've still got a Xapian source tree around from looking at
the problem I reported with x86_64 before the 3.0 release, then you can
(hopefully) reproduce my problem by running this in the tests
subdirectory:
$ valgrind --xml=yes ./btreetest 2>&1 | grep valgrindoutput
<valgrindoutput>
</valgrindoutput>
</valgrindoutput>
</valgrindoutput>
</valgrindoutput>
</valgrindoutput>
</valgrindoutput>
</valgrindoutput>
If I actually valgrind the test program it works correctly, which
probably sinks my theory about VALGRIND_DO_LEAK_CHECK:
$ libtool --mode=execute valgrind --xml=yes ./btreetest 2>&1 | grep valgrindoutput
<valgrindoutput>
</valgrindoutput>
I'm using Valgrind 3.0.1, distro is Ubuntu 5.04 on x86_64.
Cheers,
Olly
|
|
From: Manish M. <mma...@sp...> - 2005-10-04 17:07:30
|
On Mon, 2005-10-03 at 22:48 +0000, Olly Betts wrote: > I've just realised there is a fork involved, because I was running > valgrind on the libtool wrapper script, not the compiled code. > > I'm struggling to produce a simple test case right now, and don't have > a lot of spare time to work on it I'm afraid. > > Julian: If you've still got a Xapian source tree around from looking at > the problem I reported with x86_64 before the 3.0 release, then you can > (hopefully) reproduce my problem by running this in the tests > subdirectory: > > $ valgrind --xml=yes ./btreetest 2>&1 | grep valgrindoutput > <valgrindoutput> > </valgrindoutput> > </valgrindoutput> > </valgrindoutput> > </valgrindoutput> > </valgrindoutput> > </valgrindoutput> > </valgrindoutput> > > If I actually valgrind the test program it works correctly, which > probably sinks my theory about VALGRIND_DO_LEAK_CHECK: > > $ libtool --mode=execute valgrind --xml=yes ./btreetest 2>&1 | grep valgrindoutput > <valgrindoutput> > </valgrindoutput> > I tried with the wrapper libtool too, I am getting the same output. One <valgrindoutput> and number of </valgrindoutput> > I'm using Valgrind 3.0.1, distro is Ubuntu 5.04 on x86_64. > > Cheers, > Olly > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Julian S. <js...@ac...> - 2005-10-04 20:30:29
|
> > $ valgrind --xml=yes ./btreetest 2>&1 | grep valgrindoutput > > <valgrindoutput> > > </valgrindoutput> > > </valgrindoutput> > > </valgrindoutput> > > </valgrindoutput> > > </valgrindoutput> > > </valgrindoutput> > > </valgrindoutput> I believe these phenomena are due to a valgrinded process forking but not execing. I looked briefly at the printing logic in m_main.c and that is the most obvious explaination. It's not unique to XML though. You get the same nonsensical multiple-endings if you run normally, if the process forks and then both the parent and child terminate without the child doing an exec. J |