View Issue Details

IDProjectCategoryView StatusLast Update
0029959LazarusDebuggerpublic2019-01-01 19:43
ReporterColin HaywoodAssigned ToMartin Friebe 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformWin32OSWindows 7OS Version
Product Version1.4.4Product Build49931 
Target Version2.0Fixed in Version2.0 
Summary0029959: When assert is hit, debugger breaks one function call down the call stack
DescriptionWhen an assert is hit, the debugger breaks one function call down the call stack rather than on the assert itself. For example, if function A calls function B that then asserts, the debugger breaks at the line in A that called into B.

This is a bit of a nuisance when A and B are in different objects; normally you'd want to examine the properties of B (since the assert's condition likely involves properties of B), but the debugger's context is in object A, so hovering over things in B or using the Evaluate/Modify window gives the "No symbol <something> in current context" error.
Steps To ReproduceCreate a project of type "FPCUnit Console Test Application" (for some reason this doesn't reproduce with a "Simple Program" project), and use the following testcase unit:

unit TestCase1;

{$mode objfpc}{$H+}{$C+}

interface

uses
  Classes, SysUtils, fpcunit, testutils, testregistry;

type

  TAssertTest = class(TTestCase)
    published
      procedure TestHookUp();
  end;

implementation

procedure ActualTest();
  begin
    Assert(false);
end;

procedure TAssertTest.TestHookUp();
  begin
    ActualTest();
end;

initialization
  RegisterTest(TAssertTest);

end.

Compile and run the program. When the assert is hit the debugger breaks at the ActualTest() line rather than the assert itself.
TagsNo tags attached.
Fixed in Revision58283
LazTarget1.10
Widgetset
Attached Files

Relationships

related to 0032629 new FPC assert throws exception with wrong frame info 
related to 0029960 resolvedMartin Friebe Lazarus FPCUnit testcases: useless error/call stack produced if AssertFalse() etc fails 
related to 0031572 assignedMartin Friebe Lazarus Showing the wrong procedure, unit and line number at runtime error 

Activities

Martin Friebe

2016-04-03 20:18

manager   ~0091709

IIRC the problem is that fpc compiles the assert function without stack frame.

It may be possible to detect and fix from the IDE.... not sure

Colin Haywood

2016-04-03 20:23

reporter   ~0091710

(Sorry, I forgot to say you need run parameters set to "-a")

Martin Friebe

2018-06-15 22:32

manager   ~0108921

A workaround has been added to the debugger (gdb based debugger) of the IDE.

There is now an option (Tools > Options > Debugger): FixStackFrameForFpcAssert
It is on by default.

Please test, and close if ok

Colin Haywood

2019-01-01 02:35

reporter   ~0113057

Sorry for the long delay. This seems to be worse than before, now the break occurs (according to the source editor window) at the line after the call to ActualTest(). (Similar behaviour to 0029960, but at least in that one the break was in the correct function.)

The message that pops up says the assertion failed at line 21 (the Assert()), but with "At ... line 27" (the line after the call to ActualTest()).

The call stack window looks correct.

Martin Friebe

2019-01-01 18:42

manager   ~0113066

Seems it only happens in 32 bit, 64bit is fine.

Martin Friebe

2019-01-01 19:43

manager   ~0113069

I did test it.

The issue appears with 32bits, because for 32bit the default debug info (as determined by fpc itself) is "stabs" (-gs).

The detection of the frame with stabs does indeed not work. Currently there is no plan to fix this for stabs.

Simply switch your debug info to dwarf. (Which in general is the better choice).


------------------
It works for me on 32 bit Windows, using Dwarf.
Please test and close if ok. (If not re-open / comments on closed issues easily get lost).

------------------
For info, the debug info setting "default" refers to the "fpc" default. I don't know what the plans are (or if in the meantime changes where made) regarding the 32bit default setting.

One day the IDE needs its own default....

Issue History

Date Modified Username Field Change
2016-04-03 15:44 Colin Haywood New Issue
2016-04-03 15:44 Colin Haywood Status new => assigned
2016-04-03 15:44 Colin Haywood Assigned To => Martin Friebe
2016-04-03 20:18 Martin Friebe Note Added: 0091709
2016-04-03 20:23 Colin Haywood Note Added: 0091710
2017-10-12 17:29 Juha Manninen Relationship added related to 0029960
2017-10-18 15:58 Martin Friebe Relationship added related to 0031572
2017-10-30 00:52 Martin Friebe Relationship added related to 0032629
2018-06-15 22:32 Martin Friebe Fixed in Revision => 58281
2018-06-15 22:32 Martin Friebe LazTarget => 1.10
2018-06-15 22:32 Martin Friebe Note Added: 0108921
2018-06-15 22:32 Martin Friebe Status assigned => resolved
2018-06-15 22:32 Martin Friebe Fixed in Version => 1.10
2018-06-15 22:32 Martin Friebe Resolution open => fixed
2018-06-15 22:32 Martin Friebe Target Version => 1.10
2019-01-01 02:35 Colin Haywood Note Added: 0113057
2019-01-01 18:42 Martin Friebe Note Added: 0113066
2019-01-01 18:42 Martin Friebe Status resolved => assigned
2019-01-01 18:42 Martin Friebe Resolution fixed => reopened
2019-01-01 18:58 Martin Friebe Fixed in Revision 58281 => 58283
2019-01-01 19:43 Martin Friebe Note Added: 0113069
2019-01-01 19:43 Martin Friebe Status assigned => resolved
2019-01-01 19:43 Martin Friebe Fixed in Version 1.10 => 2.0
2019-01-01 19:43 Martin Friebe Resolution reopened => fixed
2019-01-01 19:43 Martin Friebe Target Version 1.10 => 2.0