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.
