<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=iso-8859-2">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Gabor,</p>
    <p>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.</p>
    <p>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.<br>
    </p>
    <p>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.</p>
    <p>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.<br>
    </p>
    <p>Otherwise, yes, it would be really useful to be able to find
      where this exception is being raised.<br>
    </p>
    <p>Tony Whyman</p>
    <p>MWA<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 09/03/18 09:14, Gabor Boros via
      Lazarus wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:3cef622d-8155-25d7-65b2-647d649d6374@bgss.hu">Hi All,
      <br>
      <br>
      The result of the attached example (which use MWA's Firebird
      Pascal API) for me is an exception:
      <br>
      <br>
      <br>
      Gstat execution time Fri Mar  9 09:29:18 2018
      <br>
      <br>
      Database header page information:
      <br>
              Flags                   0
      <br>
              Generation              173
      <br>
              System Change Number    0
      <br>
              Page size               8192
      <br>
              ODS version             12.0
      <br>
              Oldest transaction      161
      <br>
              Oldest active           162
      <br>
              Oldest snapshot         162
      <br>
              Next transaction        164
      <br>
              Sequence number         0
      <br>
              Next attachment ID      27
      <br>
              Implementation          HW=AMD/Intel/x64 little-endian
      OS=Linux CC=gcc
      <br>
              Shadow count            0
      <br>
              Page buffers            0
      <br>
              Next header page        0
      <br>
              Database dialect        3
      <br>
              Creation date           Feb 2, 2018 14:07:24
      <br>
              Attributes              force write
      <br>
      <br>
          Variable header data:
      <br>
              *END*
      <br>
      Gstat completion time Fri Mar  9 09:29:18 2018
      <br>
      <br>
      Heap dump by heaptrc unit
      <br>
      355 memory blocks allocated : 948252/948432
      <br>
      355 memory blocks freed     : 948252/948432
      <br>
      0 unfreed memory blocks : 0
      <br>
      True heap size : 131072
      <br>
      True free heap : 131072
      <br>
      An unhandled exception occurred at $00007FF97F0A3147:
      <br>
      EAccessViolation:
      <br>
        $00007FF97F0A3147
      <br>
      <br>
      <br>
      If comment out cthreads from the uses the exception is:
      <br>
      <br>
      <br>
      An unhandled exception occurred at $00007F21B71F5147:
      <br>
      EAccessViolation:
      <br>
        $00007F21B71F5147
      <br>
        $00007F21B71F751B
      <br>
        $00007F21B71F769C
      <br>
        $00007F21B746BFFF
      <br>
      <br>
      <br>
      If run with gdb (and cthreads):
      <br>
      <br>
      <br>
      Heap dump by heaptrc unit
      <br>
      355 memory blocks allocated : 948252/948432
      <br>
      355 memory blocks freed     : 948252/948432
      <br>
      0 unfreed memory blocks : 0
      <br>
      True heap size : 131072
      <br>
      True free heap : 131072
      <br>
      [Thread 0x7ffff5991700 (LWP 2874) exited]
      <br>
      [Thread 0x7ffff6192700 (LWP 2873) exited]
      <br>
      [Thread 0x7ffff7fe3740 (LWP 2869) exited]
      <br>
      Cannot find user-level thread for LWP 2875: generic error
      <br>
      <br>
      <br>
      Any idea how to detect what/where is the source of the exception?
      <br>
      <br>
      I use Linux 64bit, FPC 3.0.4 and Lazarus fixes_1_8.
      <br>
      <br>
      Gabor
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
    </blockquote>
    <br>
  </body>
</html>