I found out that there is no line information shown (-gl) if an error occurs (more or less shortly) after the program loads a dynamic library.

This same behaviour happens with fpc version 2.4.2-0 and 2.6.0.

If no library is loaded line information is shown. The error adresses are the same in both cases.

What OS? Are you expecting a line number associated with code in the calling program or the .DLL/.so? What has caused the error- is the calling convention etc. correct?

Linux

Are you expecting a line number associated with code in the calling program or the .DLL/.so?

Expecting: line xxx of yyy.pas
But when loading a library only adresses are shown.

What has caused the error

simple access violation

- is the calling convention etc. correct?

I hope so because the program runs 24/7 in some places in eurpoe.

Mark Morgan Lloyd wrote

Are you expecting a line number associated with code in the calling program or the .DLL/.so?

By now only the main program if affected.

This is about debug info written by "DumpStack" or similar (written by the exe itself, to the console)?

Or debug info shown by gdb using "bt"?
If the first, does the latter work?

As from your other replies, the exception occurs in your pascal code. But is this code in a callback from the DLL? (This would mean that stackframes of the DLL exist, and they have no line info) Or could for any other reason (including compiled with optimization) there be a stackframe (just one) that has no line info?

IIRC the line-info on stacktraces is only displayed until the very first time a line without info is discovered.
That is:
1) If within the current stackdump a line without info is discovered, then no further line will be attempted to be resolved (even if info could be available)
2) If in a previous dump, such a line was discovered, then in any further dump (even though unrelated) no line info is printed.

In Lazarus the leak view, can attempt to resolve such traces. It requires the exact exe with debug info.

?
It is a console program with graphic output to the framebuffer. When loading succesfully the library (which depends on the x11 library) the framebuffer is written to an XWindow (Linux). The software runs with a plain (embedded) linux and also in an XWindow environment.

I have only the information of what the exe program writes down in case of an error. No other debug tool is used by now. Specially when the program runs outside it will be not easy to use additional tools, I think.

As from your other replies, the exception occurs in your pascal code. But is this code in a callback from the DLL?

(Linux Library *.so)
No.

May be.

With not loading the library it shows all lines correctly.

2) If in a previous dump, such a line was discovered, then in any further dump (even though unrelated) no line info is printed.

But why are the lines not shown if there is only one line without info?

In Lazarus the leak view, can attempt to resolve such traces. It requires the exact exe with debug info.

You load the lib dynamically? e.g OpenLibrary?

If it is hardlinked (procedure ... external) then this changes the exe, and the linker may move stuff around (including debug info, and maybe debug info gets broken).
On some platform samrtlinking, also has a real risk of breaking debug info...

If it is via OpenLibrary (e.g. you can control the usage via commandline switch, and therefore truly have the same exe, then I do not know...

There may be other reasons, that I do not know of.

You can always (not sure if it works for PIE / position independent) take the address, and have gdb check, if it can be resolved).

> 2) If in a previous dump, such a line was discovered, then in any > further dump (even though unrelated) no line info is printed. But why are the lines not shown if there is only one line without info?

Missing recovery in the implementation...

Now this is from memory. double check it..... I may well remember this wrong.

Basically, if an error happens (exception) during a trace is printed, then this could lead to a new trace, a new error, a new trace ... a stackoverflow.
So during a trace, the pointer to the trace prog, is set to the basic "address only" prog.

Unfortunately there is no distinction between errors. So not finding a line is an error (IIRC it is handled the same as if dbg info is invalid/broken), and that is the end...

How is the library being loaded: using FPC's dynlibs unit?

If using dynlibs, is the problem immediately after loading the library (.so) or is it on a call of an entry point in the library?

Is the DLL successfully called, does it exit predictably, and does the stack recover to the state it was on entry (i.e. without an extra or missing word)?

Yes.

If using dynlibs, is the problem immediately after loading the library (.so) or is it on a call of an entry point in the library?

Immediately after loading the library.

The program restarts some times and there is no error. Stack recovery I don't know. I think it will be ok. How can I see that? I use loadlibrary and freelibrary.
There are only 3 functions/procedures calling from the program. (init_proc, loop_proc, exit_proc).
The library calls back a procedure (add a key to a keybuffer) but in this procedure there is no error.
I tried safeloadlibrary but the same thing.

For debugging the best would be to write down as much information as possible. Even if it causes (eventually) more (endless) errors. Would this be possible? May be with a switch?

In which case I presume that you could comment out the calls to the entry points in the library and duplicate the problem (have you tried this?). Does the recently-added GetLoadError() function tell you anything useful?

If it's specifically something that happens at load time then below probably isn't relevant.

Stack recovery I don't know. I think it will be ok. How can I see that?

Inline assembler to dump esp and ebp.

The error is produced immediately after loading (not executing) the library (writing to a random memory adress).

I did not find information of the GetLoadError() function.

?