[Lazarus] How to catch an unhandled exception?

[Tony Whyman]

Gabor,

I can't duplicate your problem which probably implies that we are 
looking at some weird race condition during the program tidy up phase. I 
did see occasionally something like this before with Lazarus 1.6.4 on 
Windows with heaptrc - but I never saw it without heaptrc and it cleared 
up with Lazarus 1.8 and hence  I never bothered to pursue it assuming 
that it was a Lazarus bug that got fixed.

You are seeing this problem not so much with IBX, but with the Firebird 
Pascal API. Your example program has excluded the IBX part and focused 
purely on the API.

What might be an issue here is that the FirebirdAPI is accessed via a 
COM interface and the IFirebirdAPI interface is not explicitly released. 
The software just relies upon the system to clean it up at the end. 
There may be a race condition here between the clear up of the interface 
and the dynamic library manager. This is because when the interface is 
released, it then unloads the Firebird DLL/SO. Try adding a finalization 
clause to IB.pas setting "FFirebirdAPI := nil" and see if that clears it 
up - or whether the exception occurs before this point.

It is not obvious if there is a real issue with cthreads. The library 
should only create multiple threads when handling asynchronous Firebird 
events and your program is not using this capability.

Otherwise, yes, it would be really useful to be able to find where this 
exception is being raised.

Tony Whyman

MWA


On 09/03/18 09:14, Gabor Boros via Lazarus wrote:
> Hi All,
>
> The result of the attached example (which use MWA's Firebird Pascal 
> API) for me is an exception:
>
>
> Gstat execution time Fri Mar  9 09:29:18 2018
>
> Database header page information:
>         Flags                   0
>         Generation              173
>         System Change Number    0
>         Page size               8192
>         ODS version             12.0
>         Oldest transaction      161
>         Oldest active           162
>         Oldest snapshot         162
>         Next transaction        164
>         Sequence number         0
>         Next attachment ID      27
>         Implementation          HW=AMD/Intel/x64 little-endian 
> OS=Linux CC=gcc
>         Shadow count            0
>         Page buffers            0
>         Next header page        0
>         Database dialect        3
>         Creation date           Feb 2, 2018 14:07:24
>         Attributes              force write
>
>     Variable header data:
>         *END*
> Gstat completion time Fri Mar  9 09:29:18 2018
>
> Heap dump by heaptrc unit
> 355 memory blocks allocated : 948252/948432
> 355 memory blocks freed     : 948252/948432
> 0 unfreed memory blocks : 0
> True heap size : 131072
> True free heap : 131072
> An unhandled exception occurred at $00007FF97F0A3147:
> EAccessViolation:
>   $00007FF97F0A3147
>
>
> If comment out cthreads from the uses the exception is:
>
>
> An unhandled exception occurred at $00007F21B71F5147:
> EAccessViolation:
>   $00007F21B71F5147
>   $00007F21B71F751B
>   $00007F21B71F769C
>   $00007F21B746BFFF
>
>
> If run with gdb (and cthreads):
>
>
> Heap dump by heaptrc unit
> 355 memory blocks allocated : 948252/948432
> 355 memory blocks freed     : 948252/948432
> 0 unfreed memory blocks : 0
> True heap size : 131072
> True free heap : 131072
> [Thread 0x7ffff5991700 (LWP 2874) exited]
> [Thread 0x7ffff6192700 (LWP 2873) exited]
> [Thread 0x7ffff7fe3740 (LWP 2869) exited]
> Cannot find user-level thread for LWP 2875: generic error
>
>
> Any idea how to detect what/where is the source of the exception?
>
> I use Linux 64bit, FPC 3.0.4 and Lazarus fixes_1_8.
>
> Gabor
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180309/b1dbc57e/attachment.html>