release mode find error at line number

[Packs]

Dear All,

I have a Lazarus command-line application that exposes a REST API. In release mode I am seeing runtime errors (for example, access violations), but I cannot determine the source file and line number where the error occurs.

So far I have tried:

Top-level exception handling and logging E.Message.

Using third-party components and libraries (which may be involved).

A few basic debugging steps (rebuilds, testing in the IDE).

[cdbc]

Hi
Switch to 'Debug' mode... 
/b

[Packs]

Thanks

[Packs]

if I build debug application and deploy while closing getting following error and it is not closing also
---------------------------
Error
---------------------------
  $000000010004E2  $0000000100026CBE

  $0000000100025DC0

Call trace for block $00000000063D2B30 size 2551

[dbannon]

Packs, are you running the application in the Lazarus IDE so the debugger can catch the problem ? If you are running from the command line, you may need to use an external debugger, gdb to so so.


If the IDE, perhaps check the debugger is configured correctly ?  And that the debug mde you have selected really does have the necessary debug settings. You might need to tell us which version of OS and FPC/Lazarus you are using to get more specific advice on how to do so.

Davo

[Zvoni]

Or use Try/Except at critical code, and then log UnitName and Linenumber to a textfile
there are ready-to-use macros for that
https://wiki.freepascal.org/$include

Or use LazLogger
https://wiki.freepascal.org/LazLogger

[jamie]

In one my Delphi apps that I sold, I created a MAP file of the final project and stashed that away on each final version project.

  If the program faulted on a user, it would generate a addresses and with that report I could look at the MAP file and determine where the issues are without distributing a debug version of the code.

  I don't know if FPC can generate a MAP file like that for the release version?

Jamie

[n7800]

FPC can create a separate file with debug data.

And it seems like you can just try rebuilding (in debug) the same version with the same options. But there are a lot of nuances. This was discussed somewhere on the forum, and Martin described it in detail.

[jamie]

Having the compiler create a map file shouldn't be a big issue since all the symbol tables have been created during the process anyways.

[PascalDragon]

Having the compiler create a map file shouldn't be a big issue since all the symbol tables have been created during the process anyways.

The switch for a map file is -Xm.

[jamie]

Perfect. Thanks

[Thaddy]

I would also recommend the use of assertions for such things: these can be turned of with one switch. When assertions are off, code generation is not affected compared to leaving them out.

[jamie]

it looks like I need to write a util for that generated output of the map file.

It's not selective as to what you need to see.

I need to see the unit's inner functions and procedures addresses and so on, not the complete log of the paths etc.

But it's nice to have that information.

 I didn't look long enough in the file to see if the actual UNIT contents are listed by use yet, I will build a until to display such things creates a file pointer table looking into the file so not to try to load the complete list in memory.

Jamie

[Thaddy]

Then you need to compile with debug info or - what I often do - generate the assembler output with -al
Release settings give otherwise very sparse info if any, so examine the assembler output (if you are capable enough versed in assembler for your CPU target)
There are only very rare - timing - cases where debug mode has different behavior from release mode. Especially if the optimization is limited to -O2.
But first try with liberately used assertions.