[SOLVED] Line Numbers on MacOS

[Key-Real]

When i compile with -gl and get a range check error,
he displays the memory addresses but not the line numbers.
Ho to get line numbers on exception?

[Thaddy]

Use -glh or -gl -gh You need both these options for sane information.
Note that the compiler and heaptrc can not always resolve the line number on exceptions in all cases, but the debugger can still make you jump to the offending line, I think. Also note the heaptrc unit in trunk is largely rewritten, so may be a better option. (Not suited to backport, I guess).

And yes, -glh also works on MacOS (tested with my Mac Mini M4)

[Martin_fr]

It may be (I vaguely recall ...) that fpc 3.2.2 does not support that. 3.3.1 should, maybe, don't know 3.2.3. (3.2.3 would be the same as the 3.2.4a of the latest Lazarus releases)

It should be possible to use lldb (or gdb) to resolve any such address into a unit/line output (if the address belongs to code with debug info).

IIRC (not tested on Mac for a long time) you can also use the IDE, menu: View > Leaks and traces.
Paste the stacktrace with the addresses, press "Resolve", select the exe (not sure if bundle, or exe within) that has the debug info, and it should hopefully resolve it.

[Thaddy]

Thanks, Martin, that is correct.
@Key-Real
Can you provide a minimal example, so I can test?
( I wrote one and that works, but I need your code before making any other assumptions)

[Key-Real]

sorry for such a late reply, I was busy and it was too hot
but now:

var xxxx : array of longint;
begin
  xxxx[123]:= 10;
.....

gives me on todays trunk:

An unhandled exception occurred at $000000010295D5A8:
EAccessViolation: Access violation
$000000010295D5A8
$0000000102987D4C
$000000010295C350
$000000010295D538
$000000018394FDA4

as i compiled, as recommended, with -glh the heap trace followed.... (nothing interesting there, btw. no line numbers there also)


                           

[Key-Real]

other test in other conditions:

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

1. {$MODE OBJFPC}
2. var
3.         xxxx : array of longint;
4. begin
5.  
6.         xxxx[123]:= 123;
7.  
8. end.

gives me:

% ./test
Runtime error 216 at $0000000100ADAC8C
  $0000000100ADAC8C
  $0000000100B0340C
  $0000000100ADAC00
  $0000000100ADAC58
  $000000018394FDA4

No heap dump by heaptrc unit
Exitcode = 216


compiled with:
/usr/local/lib/fpc/3.3.1/ppca64 test.pas -glh -Cio

[dsiders]

other test in other conditions:

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

1. {$MODE OBJFPC}
2. var
3.         xxxx : array of longint;
4. begin
5.  
6.         xxxx[123]:= 123;
7.  
8. end.

gives me:

% ./test
Runtime error 216 at $0000000100ADAC8C
  $0000000100ADAC8C
  $0000000100B0340C
  $0000000100ADAC00
  $0000000100ADAC58
  $000000018394FDA4

No heap dump by heaptrc unit
Exitcode = 216


compiled with:
/usr/local/lib/fpc/3.3.1/ppca64 test.pas -glh -Cio

You never set the length for the array.

[Key-Real]

You never set the length for the array.

its about to get the line numbers at crash

[Key-Real]

kirillkranz@MacBookPro src % /usr/local/lib/fpc/3.3.1/ppca64 test.pas -gw3 -gl -O-
Free Pascal Compiler version 3.3.1 [2026/06/22] for aarch64
Copyright (c) 1993-2026 by Florian Klaempfl and others
Target OS: Darwin for AArch64
Compiling test.pas
test.pas(6,2) Warning: Variable "xxxx" of a managed type does not seem to be initialized
Assembling (pipe) test.s
Linking test
-macosx_version_min has been renamed to -macos_version_min
7 lines compiled, 0.1 sec, 212992 bytes code, 409599 bytes data
1 warning(s) issued
kirillkranz@MacBookPro src % ./test
Runtime error 216 at $00000001005C7EAC
  $00000001005C7EAC
  $00000001005F062C
  $00000001005C7E20
  $00000001005C7E78
  $000000018394FDA4

kirillkranz@MacBookPro src % lldb test
(lldb) target create "test"
Current executable set to '/Users/kirillkranz/Documents/vip-code/test/src/test' (arm64).
(lldb) run
Process 31508 launched: '/Users/kirillkranz/Documents/vip-code/test/src/test' (arm64)
Process 31508 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1ec)
    frame #0: 0x0000000100003eac test`$PASCALMAIN at test.pas:6:6
   3         xxxx : array of longint;
   4      begin
   5      
-> 6         xxxx[123]:= 123;
   7      
   8      end.
Target 0: (test) stopped.
warning: This version of LLDB has no plugin for the language "pascal83". Inspection of frame variables will be limited.
(lldb) 

[JdeHaan]

In Lazarus Compiler options:
Set the checkbox for 'Use external debug symbols file (-Xg)'  as well.

[Key-Real]

Aha!!!

setting the -Xg option helps, BUT
he generates me an external .dSYM file.

result:

Runtime error 216 at $00000001029F3EAC
  $00000001029F3EAC line 6 of test.pas
  $0000000102A1C62C
  $00000001029F3E20
  $00000001029F3E78
  $000000018394FDA4

so now the prize question:

DO I HAVE T SHIP this .dSYM FILE WITH MY APP??????
is there no solution to write this debug info into the executable binary?

btw. I don't use Lazarus

[Key-Real]

is there no solution to write this debug info into the executable binary?

sorry I mean, it is in the binary, like we can see it with lldb in action.
Why is he didn't print me this on the screen? Only with the extra file....

[Key-Real]

wait !

MacOS needs this file, it's not compiler fault!?!?!

I'm under Tahoe 26.4

PLS confirm.

[Martin_fr]

All of the following from vague memory....

Its not the OS itself, but the file format as defined by Apple. (afaik) You can't put debug info (at least dwarf) directly into it. If you don't have a dbg file then the .o files that were used in compiling must be around.

In either case, on other OS where file formats allow the inclusion, you still get the same size => i.e. the app with debug info is much much larger -> just in one file.

Mind that debug info contains much more than line numbers. It usually also contain function names, and variable names, and all you need for a full debug info. In theory that wouldn't be needed. But afaik its not implemented to separate it (but maybe there are some tools to cut certain parts of dwarf)...


In any case, are you shipping a binary for an open or closed source? Because if the latter, then you may not want to reveal as much info as the above describes.

Even if you don't use lazarus, I am pretty sure (though I don't know the exact commands) that lldb can resolve the addresses for you. (I know gdb can, and the Lazarus IDE can, at least on non Mac, but IIRC on Mac too).

Then you would generate your exe with dbg file.
But you wouldn't ship the dbg.
When someone sends a trace, you use lldb + the dbg file (must be the exact matching for the version that printed the trace) and resolve addresses.

[Key-Real]

ok, I understand now.

THX