Recent

Author Topic: Debugger - "Broken" call stack?  (Read 3253 times)

soerensen3

  • Full Member
  • ***
  • Posts: 213
Debugger - "Broken" call stack?
« on: August 20, 2018, 10:29:56 pm »
On some errors Lazarus is showing me garbage for some functions in the stack trace. Then it becomes quite difficult to debug errors and being unable walk the function calls to the source of error.

See the attached screenshot for what I mean.

Is this because it is missing debug information for some units or because of optimization that it cannot descend lower in the call stack and some function calls have "???"? I have all my packages compiled with debug information.
Lazarus 1.9 with FPC 3.0.4
Target: Manjaro Linux 64 Bit (4.9.68-1-MANJARO)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Debugger - "Broken" call stack?
« Reply #1 on: August 20, 2018, 11:18:26 pm »
"fpc_copy" and "$init_record_operators" are part of the rtl. (The rtl is not part of the Lazarus package system)

Your fpc installation probably is prebuild:
- without debug info
- with optimization

Having no debug info means no line is shown.

Being build with optimization can (as in sometimes) mean, that the stack below a function can not be read correctly: I am certain there is no code at 00000008.
This is gotten by the debugger in error, because the optimized "$init_record_operators" uses the stack in a way, that the debugger can not know.
Often in such cases, there will be no further stack shown, but there is no rule about this.

In order to fix this you would need to build fpc from scratch. (running the make file).

Or Search for FcpUpDeluxe which can help download and build fpc.
« Last Edit: August 20, 2018, 11:20:01 pm by Martin_fr »

soerensen3

  • Full Member
  • ***
  • Posts: 213
Re: Debugger - "Broken" call stack?
« Reply #2 on: August 20, 2018, 11:39:16 pm »
Thanks for the extensive explanation. I'm using fpcupdeluxe but there seems to be no option for debug information or compile parameters so I need do "make" manually. I will try that later!
Lazarus 1.9 with FPC 3.0.4
Target: Manjaro Linux 64 Bit (4.9.68-1-MANJARO)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Debugger - "Broken" call stack?
« Reply #3 on: August 21, 2018, 02:33:10 am »
Well ok, I dont use fpcUpDeluxe, but I always read it should be able to do this.

From a googled screenshot, I would guess: "Compile Options" > "FPC Options"
you should need
-O- -gw -godwarfsets

And what ever else you like
make OPT="-O- -gw -godwarfsets"

You can (if you have the same version / best install to a new location) copy the optimized fpc and ppc binaries to the new install. All you need is the RTL (ppu and o files) that are not optimized.

soerensen3

  • Full Member
  • ***
  • Posts: 213
Re: Debugger - "Broken" call stack?
« Reply #4 on: August 21, 2018, 10:19:53 pm »
Oh must have missed that. It was not very obvious being tired and all.

It worked though BUT the error magically disappeared. It must have something to do with "optimizations". I still don't get management operators..  %)
Lazarus 1.9 with FPC 3.0.4
Target: Manjaro Linux 64 Bit (4.9.68-1-MANJARO)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Debugger - "Broken" call stack?
« Reply #5 on: August 21, 2018, 10:51:03 pm »
In your original post, the lines with the ? are likely caused by a missing or incorrect stackframe in the procedure above.

FPC has 2 directives t {$OPTIMIZATION STACKFRAME} and {$STACKFRAMES OFF}
On top of this I do not know what happen for
- asm routines
- build in / compilerproc routines
- (routines in 3rd party dll and the OS kernel will often have no useful stackframe either)

What happens:

If you call a subroutine, the callers address goes on the stack. The debugger will look for it there, this is the only place it can be found.
But the called routine will also use space on the stack for local vars. And the debugger must know how much or it can not find the caller address.
There is a convention (OS dependent) to create a stackframe, by storing the stackpointer before adding locals. This is stored in the BasePointer register, and thus the debugger can find the info.
Some procedures do not do this. And then the debugger gets lost. (Not sure, if/when extra info may get stored in the debug info / Not sure how well gdb would use it).

So if some routine still breaks the stack, find it and check if the above may apply.

------------------
There may be a bug https://bugs.freepascal.org/view.php?id=34159
I am not sure if this affects the interpretation of the stack (just a very wild guess). If it does, try compiling with -al (slower).

 

TinyPortal © 2005-2018