Hi

I asked this on Lazarus list but it belongs better here. So, how to get to the source line that gives a range check error?

I built the whole Lazarus with -Cr and debug it. When the range error happens, it only shows a RunError or similar and doesn't show me the faulty source line.
When closing Lazarus I get many notes like this:
Call trace for block $00007F8404FF23E0 size 55
$... hex numbers ...

I tried running under gdb but it didn't give any meaningful output either.

Maybe I have missed some setting? How do other people check for range error in a big project?
In a smaller project it is not a problem because you can debug into the point where the error happens.

I have a 64-bit Linux.

Juha

Juha Manninen wrote

I asked this on Lazarus list but it belongs better here. So, how to get to the source line that gives a range check error?

Compile with -gl, or set a breakpoint on FPC_RANGEERROR

Jonas

Jonas Maebe wrote

Compile with -gl, or set a breakpoint on FPC_RANGEERROR

Forgot to tell, I compiled with "-gw -gh".
"-gw" should be as good as "-gl".
Now I tried with -gl but no luck. I get an Assembly window: http://koti.phnet.fi/juhamann/Lazarus/AssemblyRangeCheck.jpg but no source lines.

For FPC_RANGEERROR, I found this in FTL system.inc:

  procedure fpc_rangeerror;[public,alias:'FPC_RANGEERROR']; compilerproc;
  begin
    HandleErrorFrame(201,get_frame);
  end;

I didn't even know there is such syntax in this language. Should I build the compiler with debug info?
I think I will leave it for now and debug Lazarus without -Cr.

The program (Lazarus) works when built without range checks. Maybe the errors are not "real" errors and could be solved by strict types. Or, maybe the memory corruption happens so seldom that nobody notices.

When testing the Delphi converter I get many such errors, maybe because the input data is unpredictable.

In any case FPC should give better feedback to the user about range check errors. A RunError and an Assembly window are quite useless.

Regards,
Juha

P.S.
Because of "-gh" I am getting the following output always when closing Lazarus. Only the numbers change with Lazarus versions and compile options.

Likely it is not a "real" error. Vincent Snijders suspected it is a bug in the way heaptrc does its counting in a 64-bit system. In a 32-bit system it works.

Heap dump by heaptrc unit
4323916 memory blocks allocated : 939864995/951779128 4323916 memory blocks freed : 939864995/951779128 0 unfreed memory blocks : 0
True heap size : 1048576
True free heap : 1924768
Should be : 1048576

2010/10/2 Juha Manninen (gmail) :

Hi Juha,

I just tried and can confirm that a LCL app running inside Lazarus (r27491), having turned on range checks is able to perfectly catch and show the place of an range check error (Ubuntu 10.04/AMD64). What I've not tried, but suggest to try, is to open the Lazarus project in Lazarus and run it as the tes app I'm talking above. Maybe then it will show nicely also the range check error sources in Lazarus itself.

HTH

PS: The test app main form unit source

unit Unit1;
{$mode objfpc}{$H+}
interface

uses
Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls;

type
  { TForm1 }
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
    procedure FormCreate(Sender: TObject);
  private
    F: Byte;
  public
    { public declarations }
  end;
var
  Form1: TForm1;
implementation
{$R *.lfm}

{ TForm1 }

procedure TForm1.Button1Click(Sender: TObject);
begin
  F := F + 1;
end;
procedure TForm1.FormCreate(Sender: TObject);
begin
  F := High(F);
end;
end.

It has nothing to do with being "as good as", they do different things (just like "-gw" and "-gh" do different things).

Now I tried with -gl but no luck. I get an Assembly window: http://koti.phnet.fi/juhamann/Lazarus/AssemblyRangeCheck.jpg but no source lines.

-gl shows the source code lines next to the hexadecimal addresses when a backtrace is printed to the console. The assembly window in that screenshot is completely unrelated.

Should I build the compiler with debug info?

That is not required.

In any case FPC should give better feedback to the user about range check errors. A RunError and an Assembly window are quite useless.

FPC nor the RTL ever show assembly an window. That is something Lazarus-specific. And when Lazarus shows an assembly window, it presumably can also show a callstack window.

As long as it says "0 unfreed memory blocks : 0", there is no problem.

Jonas

I tested with your code and yes, Lazarus places the cursor to the correct line. In addition it shows the RunError and the Assembly window just like when debugging Lazarus.

My Lazarus is now built using the Configure Build Lazarus Window. I will build it throught the lazarus.lpi project later and tell what happens.

Hmmm... maybe Lazarus is too big for FPC and it chokes... Or maybe Lazarus is too big for itself :-)

Juha

I have used only -gw and debugging works fine.
Maybe I should use both -gl -gw.
Anyway, I made a clean build wirh -gl and still had the problem. I will do some more experiments...

As long as it says "0 unfreed memory blocks : 0", there is no problem.

Ok.
The last 3 lines practically say Lazarus has a memory corruption or leak or something, while it does not have. It is OK not that I know it.

Juha

Juha Manninen wrote

Anyway, I made a clean build wirh -gl and still had the problem. I will do some more experiments...

Debug and Line Info information is missing in FPC under 64-bit Linux, even with -gl parameter enabled. This is clearly noticeable if you use the 'fpprofiler' project under 64-bit linux. No function name information, and line numbers are completely wrong.

I'm not sure if your issue is related, but is sure sounds like the same problem. The issue I am talking about does not exist under 32-bit FPC though.

Of course it works fine, -gl does not change anything about debugging. As I wrote in the part you cut away: "-gl shows the source code lines next to the hexadecimal addresses when a backtrace is printed to the console."

Maybe I should use both -gl -gw.

If you want line info printed next to backtraces printed to the console when a run time error occurs, then yes.

Anyway, I made a clean build wirh -gl and still had the problem. I will do some more experiments...

Maybe Lazarus stops the program before the backtrace is printed. In that case you should look at its callstack window once the program is stopped (assuming Lazarus provides one), or let the program continue executing after it has been stopped by Lazarus so that the program can print the backtrace to the console.

Jonas

Hello FPC-Pascal,

Saturday, October 2, 2010, 3:07:36 PM, you wrote:

JMg> Forgot to tell, I compiled with "-gw -gh".
JMg> "-gw" should be as good as "-gl".
JMg> Now I tried with -gl but no luck. I get an Assembly window: JMg> http://koti.phnet.fi/juhamann/Lazarus/AssemblyRangeCheck.jpg JMg> but no source lines.

The assembly window in Lazarus is shown when no backtrace line is available to point the cursor in, so open callstack "View -> Debug -> Callstack" and you will see that there is no available backtrace, maybe except the fpc sources without debug information (you will see some, usually 3, function names). The backtrace is often damaged when memory corruption happends and usually calling a non initialized object and not nil of course (as freed objects with heaptrc are signaled with a magic number).

That's incorrect.

$ cat tt3.pp
{$r+}
procedure test;
var
  b: byte;
begin
  b:=255;
  b:=b+1;
end;
begin
  test;
end.

$ ppcx28 -gl tt3
Target OS: Linux for x86-64
Compiling tt3.pp
Linking tt3
12 lines compiled, 2.9 sec

$ ./tt3
Runtime error 201 at $00000000004001C3
$00000000004001C3 line 7 of tt3.pp
$00000000004001D6 line 11 of tt3.pp
$0000000000400180

One thing to keep in mind: FPC's way of handling DWARF debug information (which is used by default on Linux/x86_64) is incompatible with smart linking. FPC 2.5.1 and 2.4.2 automatically disable smart linking when using DWARF debug info (and prints a warning about this), but FPC 2.4.0 may not yet do that.

Jonas

Jonas Maebe wrote

> Debug and Line Info information is missing in FPC under 64-bit Linux, > even with -gl parameter enabled. That's incorrect.

I only have a 64-bit 'll post a sample program and output to show the issue on Monday. The issue appears in fpcunit and fpprofiler. I was using FPC 2.4.3 and FPC 2.5.1

2010/10/2 Jonas Maebe :

I agree with Jonas, there is no problem.

True free heap : 1924768
Should be : 1048576

In my experience the "should be line" occurs on win32 as often as on win64.

Vincent

2010/10/2 Juha Manninen (gmail) :

The last 3 lines practically say Lazarus has a memory corruption or leak or something, while it does not have. It is OK not that I know it.

True heap size : 1048576
True free heap : 1924768
Should be : 1048576

It just says that heaptr didn't calculate the True free heap size correctly.

VIncent

Right. I finally found some errors.

One was a real error in my code, freeing an object twice, which happened seldom. For some reason Lazarus could not take me to its source line either. FPC output showed the place one level up in the call stack.

Lazarus Debugger code causes one range error which can be fixed with a typecast. FPC showed the point clearly. Issue #0017537.

TApplication.HandleException Range check error
Stack trace:
$000000000115AA93 line 1541 of ../debugger/gdbmidebugger.pp $0000000000786075
$00000000011678C7 line 3884 of ../debugger/gdbmidebugger.pp $0000000000E53D13 line 1819 of ../debugger/debugger.pp ...

I think this is a Lazarus specific problem but I always get RunError(216) window when there is a range error. Sometimes I get a SIGSEGV window, too, while there is only a range error.

Juha

Either way, this should then be reported as a bug - though a minor one because unfree'ed count is correct (zero).

Hello FPC-Pascal,

Sunday, October 3, 2010, 9:10:34 AM, you wrote:

JMg> Lazarus Debugger code causes one range error which can be fixed with a JMg> typecast. FPC showed the point clearly. Issue #0017537. JMg> TApplication.HandleException Range check error JMg> Stack trace:
JMg> $000000000115AA93 line 1541 of ../debugger/gdbmidebugger.pp JMg> $0000000000786075
JMg> $00000000011678C7 line 3884 of ../debugger/gdbmidebugger.pp JMg> $0000000000E53D13 line 1819 of ../debugger/debugger.pp JMg> ...

Please report the bug. Yes the result is integer and in 64 bits, this looks like a problem.

Hello FPC-Pascal,

Sunday, October 3, 2010, 11:41:00 AM, you wrote:

GG> Either way, this should then be reported as a bug - though a minor one GG> because unfree'ed count is correct (zero).

I could be wrong, but it seems caused because heaptrc can only control memory blocks allocated after its initialization, so any memory allocated before can not be counted as right or wrong.

I think this is an issue I reported back in March, though I can now see I uploaded the wrong patch for it

Colin

Sorry - meant to add: http://bugs.freepascal.org/view.php?id=16132

I reported it already earlier as issue
#17537: Debugger: added a typecast to prevent a range check error

I added your issue as a duplicate. Our patches are different but both work (although mine is shorter :-)

Anyway this is a good example of a valid Lazarus patch that is ignored, again. :-(

Juha

Juha Manninen wrote

Anyway this is a good example of a valid Lazarus patch that is ignored, again. :-(

Ok, sorry Lazarus guys, I must take this one back. The valid patch was uploaded only today so it was not really ignored.

Now there are 2 valid patches to choose from.

Juha

CCed to lazarus list, as it's lazarus now.

Juha: did Marc say, he wanted it, or did you just assign it because it's debugger? (e.g. in the later, I don't mind taking it over)

btw: I would modify the shorter patch, and introduce a type (similar like there is PtrInt)
TDbgPtrInt = 64

declared at the same location as TDbgPtr is declared => if someone changes TDbgPtr, then they should see (and change) the new type too.

Hi Jonas

See the bug report for details. Not all the information available under 32-bit FPC is available under 64-bit FPC.

http://bugs.freepascal.org/view.php?id=17547

.... so your statement should have been 'debug and line info information is incomplete', instead of 'missing'

IT is about 0 and 1, so any statement about it should be precise as well :-)

Michael.

Op 2010-10-05 11:17, Michael Van Canneyt het geskryf:

.... so your statement should have been 'debug and line info information is incomplete', instead of 'missing'

It was for "dramatic effect".... :) You are right, my initial statement was a bit wrong - I didn't have the code or output in front of me at the time so when from memory (which seems to be fading sometimes).

Regards,
- Graeme -