[SOLVED]How did I manage to screw up debugging in lazarus

[Martin_fr]

Did you system/OS receive any updates lately?

E.g. could the linker have been upgraded?

[cdbc]

Just now I tried to run laz with your params:

Code: Text  [Select][+][-]

1. lazarus-ide   --debug-log=DBG   --log-enable=DBG_STATE,DBG_DATA_MONITORS,DBG_ERRORS,DBG_VERBOSE,DBG_WARNINGS,DBG_BREAKPOINTS,DBG_FPDEBUG_VERBOSE,FPDBG_BREAKPOINT_ERRORS,FPDBG_BREAKPOINTS
2.  

Attached is the file...
Funnily enough, this time I succeeded in stepping through the small test, ended in a segfault though?!?
I'm very puzzled 

[cdbc]

Well yes possibly, I do a system-update ca. once a week, it's been about 5 days or so... could be around that time, it all went to H*ll in a handbasket.

[cdbc]

If I start laz normal, it's back to freezing...

[Martin_fr]

Ok, so it seem the logging framework doesn't work either. That however isn't a problem an your side. I just tested, it seems that it doesn't work with the official builds.

So back to square 1.

You said the same issue happens when you use gdb as debugger?
If so, then open Menu: View > Ide Internals > Debug Output   (could be that 2.2.6 still has this in "Debug Windows" submenu, but must be "debug output", not console).

Switch to gdb, run => and get the content of that window.  (window must be open *before* run).

Also for sanity reasons => a new project with just a few lines of code => that will work in the debugger?

[cdbc]

Ok, here's output from gdb in "Debug Output"
Tried to paste it here... file is in attachment.
It had a lot to say 

[cdbc]

hmm.. gdb no likey.

[cdbc]

And  the sanity check looks like the attachment... 

[Martin_fr]

OK according to the debug out text, gdb reached the breakpoint at the "begin" line.  (line 48).


Anyway gdb confirmed that the line info for the file (the "program foo;" file) is ok.
There are lines from 15 with gaps to 70. And the have sensible addresses (it's 32 bit, isn't it?)


I wonder on your asm image "fpc_initializeunits" => how did you stop there.
If I look at the debug output, you single stepped.
Did you single step from the "begin" line?

Then that would mean that FPC packed the call to run all the "initialization" sections into that begin line.

Which then means, could it be that there is some code in any initialization section that runs forever (and does whatever you see the app doing)?
Then of course no other breakpoint would be reached.

[Martin_fr]

If you run your app, and it runs past the begin, but doesn't reach the next line.
If you then press pause.

The asm will pop up => Ignore that, open the stack window, and see if it shows anything (maybe some unit is somewhere in the list of callers)

You may need to try that with gdb or fpdebug / gdb (if it does not crash) may be better at finding the stack. But if gdb crashes, then try fpdebug.

[cdbc]

Okidoki, makes sense, btw. it's 64 bit machine/os/fpc/laz
I'll try to hunt down a/some initialization sections and have a looksee...
yes I single-stepped from "begin"
Will try your suggestions, think I have to reboot my machine now, this fiddling with GDB have made it sluggish  :'(
will report back here, with my progress...
Thanks so far Martin 
Regards Benny

[cdbc]

Hi
Pheeeewwwww.... finally back on track 
In my search-quest, I found not a(ny) intialization "BuBu", but instead:
1) In a class that gets used as a kinda plugin(like fpimage architecture) and
   will end up in a library as a real plugin, I found a double-free, checking for
   nil is no good, when you call free  In the process I learnt, that FreeAndNil
   doesn't check for nil  Somehow FpDebug was aware of that...
2) In a key containerclass I'd somehow managed to keep inheritance, but
   new/re-introduce the interfaces it supports, which resulted in an
   "Interfaces are not related" warning from fpc and the need to typecast a
   hole slew, throughout the code, even though, they clearly were the same
   interfaces and classes  What a hype & a mess 
After I got the D*MNED double free out of the way, I could slowly start debugging again, but FpDebug kept crashing at random places in the code, then I scrutinized the whole code-tree and found the just as subtle 2) bug.
So Kudos to FpDebug, well spotted, but you could just have said so 
That took a lot of coffee and cigarettes... Thank you Martin_Fr for your help, in getting me as far as I could debug a little and find my way 
Regards Benny

[Martin_fr]

double free and nil stuff.....

If you are on Linux, or can run your app in a Linux VM => valgrind --tool=memcheck yourapp
The resulting traces can be loaded into the IDE menu: view > leaks and traces

(Afaik under fpc trunk using llvm as backend, there are settings for similar checks / but not yet gone there myself)

Code: Pascal  [Select][+][-]

1. but FpDebug kept crashing at random places in the code

FpDebug, aka the IDE ? I.e. the IDE said it had a crash, and may be corrupted?
Or your app crashed under FpDebug?

In case of the former, it be interesting if Lazarus 3.0 still crashed... But since you fixed the stuff....

[cdbc]

Hi
It was crashing while debugging in the IDE, then I noticed in the console output(started lazarus-ide in konsole) that some internal debugger classes tripped over some interface stuff of mine, from then on things moved forward...
I really respect the amount of work you've put into FpDebug, thanks...
Everything is now back to normal and I've learnt a few things, along the way.
Regards Benny

[Martin_fr]

that some internal debugger classes tripped over some interface stuff of mine, from then on things moved forward...

"interfaces" are empty  for the debugger (just an empty structure, the methods are not in the info).

So the debugger will/should just show an empty struct "()" or similar...

But it should not "trip". When you get to 3.0, I'd appreciate if you can check if it still happens. Thanks.