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.
