Unable to use tradional tools to find memory leaks

[Flamaros]

On Monday, 23 September 2013 at 21:35:21 UTC, Flamaros wrote:
> On Monday, 23 September 2013 at 20:06:20 UTC, Flamaros wrote:
>> On Saturday, 21 September 2013 at 14:30:19 UTC, Flamaros wrote:
>>> I tried to used Valgrind (Linux) and Dr Memory (Windows) 
>>> without success to find a big leak I have in my application.
>>> But both tools can't launch my application without make it 
>>> crash.
>>>
>>> Do I need do something particular, to have a chance to see 
>>> one of those tool working fine with my application?
>>>
>>> It can be really hard to find leaks manually, maybe some 
>>> option of the gc can help me?
>>
>> Here is my Valkyrie output :
>> ===valkyrie:3014=== DEBUG: utils/vk_config.cpp#253: static bool
>> VkCfg::checkConfigDir(const QString&):
>> ===valkyrie:3014=== No existing config dir
>> '/tmp/valkyrie_flamaros/' => creating.
>> ===valkyrie:3014===
>> ===valkyrie:3014=== DEBUG: utils/vk_config.cpp#702: void
>> VkCfgProj::openProject(const QString&):
>> ===valkyrie:3014=== Can't open project: File doesn't exist, or 
>> is
>> not readable:
>> '/home/flamaros/development/personnal/dquick/data/dquick.cfg'
>> ===valkyrie:3014===
>> MainWindow::runTool( tool: 0, proc: 0 )
>> ===valkyrie:3014=== DEBUG: utils/vk_config.cpp#636: void
>> VkCfgProj::replaceConfig(QSettings*):
>> ===valkyrie:3014=== Replacing current config with:
>> /home/flamaros/development/personnal/dquick/dquick.cfg
>> ===valkyrie:3014===
>> MainWindow::runTool( tool: 0, proc: 0 )
>> Valkyrie::runTool( 0, 0)
>> Current path: /home/flamaros/development/personnal/dquick/.
>> [OpenGLContext] OpenGL Version: 2.1 Mesa 9.1.4
>> rootItem main
>> vex amd64->IR: unhandled instruction bytes: 0x48 0xDF 0x1C 0x24
>> 0x48 0xD9 0x6C 0x24
>> vex amd64->IR:   REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0
>> vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
>> vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
>> ==3017== valgrind: Unrecognised instruction at address 
>> 0x5bad9a.
>> ==3017== Your program just tried to execute an instruction that
>> Valgrind
>> ==3017== did not recognise.  There are two possible reasons for
>> this.
>> ==3017== 1. Your program has a bug and erroneously jumped to a
>> non-code
>> ==3017==    location.  If you are running Memcheck and you just
>> saw a
>> ==3017==    warning about a bad jump, it's probably your
>> program's fault.
>> ==3017== 2. The instruction is legitimate but Valgrind doesn't
>> handle it,
>> ==3017==    i.e. it's Valgrind's fault.  If you think this is 
>> the
>> case or
>> ==3017==    you are not sure, please let us know and we'll try 
>> to
>> fix it.
>> ==3017== Either way, Valgrind will now raise a SIGILL signal
>> which will
>> ==3017== probably kill your program.
>> ToolObject::processDone( 0, 1 )
>> ===valkyrie:3014=== DEBUG: objects/tool_object.cpp#687: void
>> ToolObject::processDone(int, QProcess::ExitStatus):
>> ===valkyrie:3014=== Error running VgProcess: process failed (1)
>> ===valkyrie:3014===
>> ===valkyrie:3014=== DEBUG: objects/tool_object.cpp#714: void
>> ToolObject::processDone(int, QProcess::ExitStatus):
>> ===valkyrie:3014=== VgProcess finished with error: stop 
>> VgReader
>> ===valkyrie:3014===
>> ===valkyrie:3014=== DEBUG: objects/tool_object.cpp#440: void
>> ToolObject::stopProcess():
>> ===valkyrie:3014=== Stopping VgProcess
>> ===valkyrie:3014===
>> ===valkyrie:3014=== DEBUG: objects/tool_object.cpp#488: void
>> ToolObject::stopProcess():
>> ===valkyrie:3014=== VgProcess already stopped (or never 
>> started).
>> ===valkyrie:3014===
>>
>>
>> PS : Code was generated with gdc, my application crash exactly
>> like with dmd, so it doesn't seems to be a linker issue. Maybe 
>> a
>> D spec issue or Valgrind one.
>
> I found some leaks, but not the critical one.
> It seems my objects aren't correctly released when I simply set 
> variables on a class to null. Calling explicitly clear() force 
> immediate call of destructors.
>
> I certainly need dig into that way to find my issue.
>
> PS : MTuner can launch my application without make it crash, 
> but it doesn't see memory of GC.

OK I just found my leak. That was not a real leak!!! A piece of 
code was turn off the GC and never put it back on.