Unable to use tradional tools to find memory leaks

[Flamaros]

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.