* * *

Author Topic: "-stack-list-arguments 1 0 2" did not return any resul  (Read 1084 times)

ASerge

  • Hero Member
  • *****
  • Posts: 963
"-stack-list-arguments 1 0 2" did not return any resul
« on: July 10, 2018, 09:36:51 am »
Windows, Lazarus 1.8.4, x64
Test a little prog.
Without breakpoint run OK. With breakpoint stop on it and then show error.
Also OK (stop on breakpoint) when compiler optimization is level 2 or higher :o. Very strange .
Any changes to the "Debugging" tab in the project option do not affect the result (well, of course, except disabling debugging altogether).
Ideas?

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 4887
    • wiki
Re: "-stack-list-arguments 1 0 2" did not return any resul
« Reply #1 on: July 10, 2018, 12:42:57 pm »
The big question is witch version of gdb?
Afaik included is 7.3
Alternative at https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2064%20bits/Alternative%20GDB/

Basically something seems to have crashed gdb. (Older gdb are sometimes more stable)

The 2nd question is what debug info your project uses (and what version of fpc).
Debug info applies separate to project and packages. (Stabs may cause problems / if it is supported by your version of fpc / try dwarf, but not dwarf 3 / try additions and overrides to apply it to all code).

You can also try -Xe  external linker to see if it make a difference
« Last Edit: July 10, 2018, 01:06:55 pm by Martin_fr »

ASerge

  • Hero Member
  • *****
  • Posts: 963
Re: "-stack-list-arguments 1 0 2" did not return any resul
« Reply #2 on: July 10, 2018, 03:39:47 pm »
Afaik included is 7.3
Alternative at https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2064%20bits/Alternative%20GDB/
Thanks for answer.
With 7.7 the same error.
Quote
The 2nd question is what debug info your project uses (and what version of fpc).
Debug info applies separate to project and packages. (Stabs may cause problems / if it is supported by your version of fpc / try dwarf, but not dwarf 3 / try additions and overrides to apply it to all code).
Lazarus 1.8.4, so FPC 3.0.4
I try all type of debug info (early "Any changes to the "Debugging" tab in the project option").
Quote
You can also try -Xe  external linker to see if it make a difference
With this (in Project Opttions/Custom Options) not compiled - project1.lpr(15,1) Error: Error while linking.

I try rewrite code in debugged procedure, now it's error is "-stack-list-arguments 1 0 0" with any level compiler optimization.
What is arguments for -stack-list ?

At all it seems on shamanism %). If I do Build + Compile and if the mouse cursor is NOT on any Lazarus window and if the optimization level >= 2, then the breakpoint is triggered.
"Reset Debugger after each run" already set.
The same after restart IDE.

Thaddy

  • Hero Member
  • *****
  • Posts: 7101
Re: "-stack-list-arguments 1 0 2" did not return any resul
« Reply #3 on: July 10, 2018, 04:30:02 pm »
"shamanism"  :D I agree.
Anyway, although -O2 should be very friendly to GDB can you still debug in = -01? It is not my (main) platform, but I can try tomorrow.
« Last Edit: July 10, 2018, 04:33:05 pm by Thaddy »
inline variables like in D10.3 are a bit like Brexit: if you are given the wrong information it sounds like a good idea. Every kid loves candy, but it makes you fat and your teeth will disappear.

ASerge

  • Hero Member
  • *****
  • Posts: 963
Re: "-stack-list-arguments 1 0 2" did not return any resul
« Reply #4 on: July 10, 2018, 04:40:10 pm »
"shamanism"  :D I agree.
Anyway, although -O2 should be very friendly to GDB can you still debug in = -01? It is not my (main) platform, but I can try tomorrow.
–°ontrariwise. With -O- or -O1 the debugger does not work.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 4887
    • wiki
Re: "-stack-list-arguments 1 0 2" did not return any resul
« Reply #5 on: July 10, 2018, 04:44:01 pm »
Quote
Lazarus 1.8.4, so FPC 3.0.4
I try all type of debug info (early "Any changes to the "Debugging" tab in the project option").

This still leaves packages compiled with other debug info.
Using "Additions and Overrides" you can set options for all packages. (Or change it for the package in which the breakpoint is, including 2 level of callers)

I uploaded 8.1 for 64 bit https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2064%20bits/Alternative%20GDB/
But I doubt it will make a difference.

Quote
What is arguments for -stack-list ?
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Stack-Manipulation.html

-stack-list-arguments 1 0 2
request names and values (1) of arguments (function parameters) for frames 0 to 2.

-------
Do you have any "large" values as parameters (or (maybe) even local vars)?
e.g  pointer to array[0..maxint] of foo

I know sometimes types like this are used with memalloc, so there never is on array this size. But GDB will try to alloc that memory.
There are settings in Lazarus trunk, to tell gdb otherwise

You may try and go to the debugger options and in the field "debugger_startup_options" enter:
--eval-command="set max-value-size 50000"

------------
What is the output (last couple of lines) in Menu: View > Debugger > Debug Output?

I am afraid , but it is gonna be a bit of a guessing game, since the error is in gdb.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 4887
    • wiki
Re: "-stack-list-arguments 1 0 2" did not return any resul
« Reply #6 on: July 10, 2018, 04:48:49 pm »
"shamanism"  :D I agree.
Anyway, although -O2 should be very friendly to GDB can you still debug in = -01? It is not my (main) platform, but I can try tomorrow.

You will get errors even with -O1.

For line info, and breakpoints it hardly makes a difference (as long as no inlining happens).

But values are affected.
Afaik -O1 activates the peep hole optimizer. This prevents in rare cases that a variable is written back to memory in the current statement. The write back will instead happen one statement later. Therefore the value will be wrongly displayed for the duration of one statement.

-O2 will have more side effects.

This may also be why there was no crash with O2. GDB did not see the value that crashed it.

ASerge

  • Hero Member
  • *****
  • Posts: 963
Re: "-stack-list-arguments 1 0 2" did not return any resul
« Reply #7 on: July 10, 2018, 05:51:37 pm »
This still leaves packages compiled with other debug info.
Using "Additions and Overrides" you can set options for all packages. (Or change it for the package in which the breakpoint is, including 2 level of callers)
A very simple project without any packages. I attached it to the message.

Quote
I uploaded 8.1 for 64 bit https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2064%20bits/Alternative%20GDB/
But I doubt it will make a difference.
Yes, you're right, no change.

Quote
You may try and go to the debugger options and in the field "debugger_startup_options" enter:
--eval-command="set max-value-size 50000"
No changes

Quote
What is the output (last couple of lines) in Menu: View > Debugger > Debug Output?
I finally the compared logs in normal case and erroneous. This is similar to GDB failing when trying to get a value from a complex structure variable if its value is not yet defined (out parameter).

Wait, wait... Yes!!!! After the next code rewriting, the debugger always works.

I decided to rewrite FmtBCD. I really don't like the current code. In the nested module, I debugged TryStrToBCD. A breakpoint on the first line of procedure and led to the debugger stop.
Project is very simple, init included.
Code: Pascal  [Select]
  1. program Project1;
  2. {$MODE OBJFPC}
  3. {$APPTYPE CONSOLE}
  4.  
  5. uses FmtBcdNew;
  6.  
  7. var
  8.   V: TBCD;
  9.   S: FmtBCDStringType = '12.34E5';
  10. begin
  11.   if TryStrToBCD(S, V) then
  12.     Writeln('OK');
  13.   Readln;
  14. end.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 4887
    • wiki
Re: "-stack-list-arguments 1 0 2" did not return any resul
« Reply #8 on: July 10, 2018, 06:12:14 pm »
I can reproduce it with different gdb versions (haven't tried 32 bit yet).
Anyway debugging gdb itself is not currently something I have time to put on my list...

Btw, If you go for Lazarus trunk, you may want to try LazDebuggerFp

Thaddy

  • Hero Member
  • *****
  • Posts: 7101
Re: "-stack-list-arguments 1 0 2" did not return any resul
« Reply #9 on: July 10, 2018, 06:52:32 pm »
I can reproduce it with different gdb versions (haven't tried 32 bit yet).
Anyway debugging gdb itself is not currently something I have time to put on my list...

Btw, If you go for Lazarus trunk, you may want to try LazDebuggerFp
Can you give us what gdb version? <smile> Keeps people from their normal work....
inline variables like in D10.3 are a bit like Brexit: if you are given the wrong information it sounds like a good idea. Every kid loves candy, but it makes you fat and your teeth will disappear.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 4887
    • wiki
Re: "-stack-list-arguments 1 0 2" did not return any resul
« Reply #10 on: July 10, 2018, 07:27:52 pm »
Can you give us what gdb version? <smile> Keeps people from their normal work....

I tested this particular issue under 64 bit and with fpc 3.0.4 with GDB
7.3.50 (part of the 64 bit Lazarus installer)
7.7 (avail on Lazarus sourceforge)
7.9.1
8.0.1
8.1 (avail on Lazarus sourceforge)

Note that it is gdb that crashes. But there is no knowing if fpc writes 100% correct debug info. Therefore tests with earlier/newer fpc may lead to diff results.

The following list was mainly done on 32 bit win, and it only contains older issues http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Bugs_in_GDB
There may be many more.



 

Recent

Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus