[Valgrind] Does not open the console and message window stays blanc

[Sunsawe]

Hi everyone,

I am trying to use the Valgrind plugin (from the last nightly built).
I got it running but the message window stays blanc  . I ran the command appearing in the Valgrind window

Code

valgrind --leak-check=yes --xml=yes "bin/Debug/MyApp" 

 into a shell and there, there is an output (xml).


How do I get this output nicely formatted into the message window?

Another thing, when I run my application with Valgrind inside Code::Blocks, it does not open the console for the application (so it waits user inputs forever  :shock: ). Is it normal or...?

Thank you for your help.

[killerbot]

no idea yet for the user input issue.

Could you post the output log valgrind gives; that way I can try to have a look at why I might not parse [I have an idea, but for sure not a solution]

[Sunsawe]

Sorry for the very late reply but after some changes to the project, I had to wait for it to be runnable again to test.
So the problem is still the same, nothing in the Valgrind message box. By running it into a console, I get this:

Code

<errorcounts>
  <pair>
    <count>4</count>
    <unique>0x11</unique>
  </pair>
  <pair>
    <count>3</count>
    <unique>0x12</unique>
  </pair>
</errorcounts>

<status>
  <state>FINISHED</state>
  <time>00:00:00:02.634</time>
</status>

<suppcounts>
  <pair>
    <count>17</count>
    <name>Debian libc6 (2.9.x) stripped dynamic linker</name>
  </pair>
</suppcounts>

<error>
  <unique>0x18</unique>
  <tid>1</tid>
  <kind>Leak_DefinitelyLost</kind>
  <what>179,360 bytes in 1 blocks are definitely lost in loss record 1 of 2</what>
  <leakedbytes>179360</leakedbytes>
  <leakedblocks>1</leakedblocks>
  <stack>
    <frame>
      <ip>0x40270FC</ip>
      <obj>/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so</obj>
      <fn>realloc</fn>
      <dir>/build/buildd/valgrind-3.4.1/coregrind/m_replacemalloc</dir>
      <file>vg_replace_malloc.c</file>
      <line>429</line>
    </frame>
    <frame>
      <ip>0x808ABC4</ip>
      <obj>/Development/projects/MyApplication/MyApplicationTestExe/bin/Debug/MyApplicationTestExe</obj>
      <fn>sigar_file_system_list_grow</fn>
      <dir>/Development/tools/sigar/src</dir>
      <file>sigar.c</file>
      <line>391</line>
    </frame>
    <frame>
      <ip>0x8092DB6</ip>
      <obj>/Development/projects/MyApplication/MyApplicationTestExe/bin/Debug/MyApplicationTestExe</obj>
      <fn>sigar_file_system_list_get</fn>
      <dir>/Development/tools/sigar/src/os/linux</dir>
      <file>linux_sigar.c</file>
      <line>1132</line>
    </frame>
    <frame>
      <ip>0x8052142</ip>
      <obj>/Development/projects/MyApplication/MyApplicationTestExe/bin/Debug/MyApplicationTestExe</obj>
      <fn>NokManagement::Nok_DataRetriever::InitialiseFS_List()</fn>
      <dir>/Development/projects/MyApplication/NokManagement</dir>
      <file>Nok_DataRetriever.cpp</file>
      <line>18</line>
    </frame>
    <frame>
      <ip>0x804CF4A</ip>
      <obj>/Development/projects/MyApplication/MyApplicationTestExe/bin/Debug/MyApplicationTestExe</obj>
      <fn>main</fn>
      <dir>/Development/projects/MyApplication/MyApplicationTestExe</dir>
      <file>main.cpp</file>
      <line>22</line>
    </frame>
  </stack>
</error>

</valgrindoutput>

Expiration de la minuterie durant l'établissement du profile

The last line means something like: Timer expired during profile's creation.

There are a few things that are disturbing me in this result. It refers to two files which... are not included in my project!  :shock:
To be exact, the sigar library is used inside the project. So it is linked to the includes and the .a of the library. sigar.c and linux_sigar.c are part of the source code of the library and were never included into the project. The location indicated for these files, is where the library was built before installation.

To be sure that no traces of wrong includes or wrong dependencies were still hidden somewhere, I simply deleted the entire folder with the sources and everything, compiled again with not a single complain from the compiler and then ran it again.
So this report indicates errors (leaks?) from non existing files, non included into the project, which does not depend on them...  :shock: :shock:

I start to hope that I did something wrong because... that would be really weird...

[Jenna]

If the library is build with debugging-symbols the information about the sources is saved into it.

[Sunsawe]

ah! that would explain everything. I don't know if it was but I guess so.
So back to the original issue, why is it that the Valgrind message box stays empty?

[killerbot]

do both valgrind windows stay empty ??

Valgrind should be the output as is, the valgrind messages is the result of the parse of the xml; which will fail in this case because of that last line, which turns the output into invalid xml.

[Sunsawe]

the valgrind window it self, sends just that:

Code

valgrind --version
valgrind-3.4.1-Debian
valgrind --leak-check=yes --xml=yes "bin/Debug/MyApplicationTestExe" 

[Jenna]

I don't get any output (except for the three starting lines), if I use a wxLogWindow for debugging purposes.
This might be related to your problem.

[killerbot]

Something you can try out, just to see if valgrind returns to CB, is adding the following line to your CB source tree, and rebuild CB yourself. I assume you build CB yourself, which is most often the case for linux users ;-)
insert the following line in between line 283 and 284 :

Code

	AppendToLog(_T("Valgrind returned");

Resulting in the following snippet :

Code

	wxString CommandLine = _("valgrind --leak-check=yes --xml=yes \"") + ExeTarget + _("\" ") + CommandLineArguments;
//	CommandLine = _("valgrind --leak-check=yes \"") + ExeTarget + _("\" ") + CommandLineArguments;
	AppendToLog(CommandLine);
	wxArrayString Output, Errors;
	wxExecute(CommandLine, Output, Errors);
	AppendToLog(_T("Valgrind returned");
	size_t Count = Output.GetCount();

[Jenna]

I don't get any output (except for the three starting lines), if I use a wxLogWindow for debugging purposes.
This might be related to your problem.

Valgrind definitely returns, bout both wxArrayString's are empty, the same happens, when I debug the valgrind-plugin.
So it seems to be a problem with wxExecutes redirection of output- and/or error-streams.