Unable to use tradional tools to find memory leaks

[Flamaros]

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.