Forum > Debugger
Help on how to debug inherited Destroy;
nadavvin:
Hello
I am porting Heidisql to lazarus and while until now I could comment code that cause crashing, it now failed on Destroy and the call stack does not display any useful information like where it really happen.
https://imgur.com/Bil0t3Ql.png
A little more info on manul debuging:
I fall on "inherited Destroy;" on the project source. step in lead to:
scrollingwincontrol.inc TScrollingWinControl.Destroy; step in lead to:
TCustomControl.Destroy; step in lead to:
TWinControl.Destroy
TControl.Destroy;
TLCLComponent.Destroy;
Then step in of "inherited Destroy;" of TLCLComponent.Destroy; lead to raised exception
Project heidisql raised exception class 'External: SIGSEGV'.
At address 42CE65
What can I do?
Thanks
Martin_fr:
At some time "inherited Destroy" steps into the RTL (part of fpc). This usually has no debug info. You need to compile your own fpc with debug info, if you really need to debug there. (fpupdeluxe can help).
The same applies to fpc_ansistr_*, part of the rtl.
But I doubt that stepping in there will get you closer to your problem.
Crashes in fpc_ansistr_* are 99.999% due to memory corruption, or accessing already free'd objects (including double free).
I suspect, that you may be destroying (or otherwise access) an object, that was already destroyed before. The memory of this object is then filled with whatever random data got there in the meantime, and that can cause any sort of bad effect.
In general, finding such bugs is extremely hard.
If you are an linux, the ultimate tool is "valgrind". But using it requires some background knowlegde.
The first steps that you should do, if you have not yet:
compile with
-gh -gt
You may want to set the the environment HEAPTRC=keepreleased in Run > Run Parmeter.
When you are in destroy, check the various fields of "self". If they have strange values (55555555 or AAAAAAAA or BAADF00D) then your object was destroyed before. (Even if the values are not the listed ones, check if they make sense)
In that case, you must find where the destroy had happened.
nadavvin:
Thanks for your replay, since then the project crash on run time in different so I fought it because it lazarus trunv version I use but in the end it was my code...
I try use valgrind and while I can see how many calls there are to each function, I still need to learn how to use it it above it.
I try to compile lazarus and fpc with debugging but I still cannot step in to the fpc sources.
fpc have a DEBUG option but it still contain in the compiling the flags for not debug of -Xs -O2
When I set FPCOPT=" -gh -gt" it add the the compiling but with the -Xs -O2 and the build failed
For example part of the log (not full line):
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---/usr/bin/ppcx64 -gh -gt -gl -Ur -Xs -O2 -n -FE. -FUunits/x86_64-linux -Cg -dx86_64 -dDEBUG -dRELEASE -gl -Ur -Xs -O2 -n -FE. -FUunits/x86_64-linux -Cg -dx86_64 -dDEBUG -dRELEASE -gl -Ur -Xs -O2 -n -Fux86_64
Martin_fr:
In the fpc svn checkout do
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---make all OPT=" -O- -gw"make install
you may want to specify where to install, and make sure all dependencies are fulfilled. Google the fpc "buildfaq".
You may prefer building fpc with fpcup deluxe. Search the forum.
In either case, once rebuild, make sure the new ppu are used. Install them, or adapt the fpc.cfg.
Compile your project with -va to see for each ppu where it comes from.
---
Also, maybe the crash happens in FreeInstance. Which is called *after* the destructor finishes. Not sure how normal stepping handles this, but you can use asm stepping.
---
On valgrind the tool you want to use is "memcheck"
Getting function caller info sounds like you used "callgrind"
nadavvin:
Thanks! and I found where is the double free
Navigation
[0] Message Index
[#] Next page