1

I'm using the embedded version of Firebird SQL 2.5.8 with my C# application (.NET 4.6.2, FirebirdSql.Data.FirebirdClient 5.8.0)

On a Windows 8.1 client the following error occurs if I quit the application:

Problemsignatur:
Problemereignisname:    APPCRASH
Anwendungsname: Fewo.exe
Anwendungsversion:  19.0.0.0
Anwendungszeitstempel:  5a79bf34
Fehlermodulname:    fbintl.DLL
Fehlermodulversion: 2.5.8.27089
Fehlermodulzeitstempel: 5a4f3dbc
Ausnahmecode:   c0000005
Ausnahmeoffset: 00004e9c
Betriebsystemversion:   6.3.9600.2.0.0.256.48
Gebietsschema-ID:   1031
Zusatzinformation 1:    5861
Zusatzinformation 2:    5861822e1919d7c014bbb064c64908b2
Zusatzinformation 3:    a10f
Zusatzinformation 4:    a10ff7d2bb2516fdc753f9c34fc3b069

I've created a dump file and analyzed it according to .NET console app with Firebird Client crashes on program end. This is the output:

0:000> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

*** WARNING: Unable to verify checksum for mscorlib.ni.dll
*** WARNING: Unable to verify checksum for Fewo.exe
Failed to request MethodData, not in JIT code range
GetUrlPageData2 (WinHttp) failed: 12002.

DUMP_CLASS: 2

DUMP_QUALIFIER: 400

CONTEXT:  (.ecxr)
eax=0679bb98 ebx=00000000 ecx=07314e90 edx=00004084 esi=072ae0f0 edi=0678ba50
eip=07314e9c esp=0117ebfc ebp=065fe0d0 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00210206
fbintl+0x4e9c:
07314e9c 8b86b0000000    mov     eax,dword ptr [esi+0B0h] ds:002b:072ae1a0=????????
Resetting default scope

FAULTING_IP: 
fbintl+4e9c
07314e9c 8b86b0000000    mov     eax,dword ptr [esi+0B0h]

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 07314e9c (fbintl+0x00004e9c)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 072ae1a0
Attempt to read from address 072ae1a0

DEFAULT_BUCKET_ID:  INVALID_POINTER_READ

PROCESS_NAME:  Fewo.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

EXCEPTION_CODE_STR:  c0000005

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  072ae1a0

FOLLOWUP_IP: 
fbintl+4e9c
07314e9c 8b86b0000000    mov     eax,dword ptr [esi+0B0h]

READ_ADDRESS:  072ae1a0 

WATSON_BKT_PROCSTAMP:  5a79bf34

WATSON_BKT_PROCVER:  19.0.0.0

PROCESS_VER_PRODUCT:  Fewo-Verwalter

WATSON_BKT_MODULE:  fbintl.dll

WATSON_BKT_MODSTAMP:  5a4f3dbc

WATSON_BKT_MODOFFSET:  4e9c

WATSON_BKT_MODVER:  2.5.8.27089

MODULE_VER_PRODUCT:  Firebird SQL Server

BUILD_VERSION_STRING:  6.3.9600.17415 (winblue_r4.141028-1500)

MODLIST_WITH_TSCHKSUM_HASH:  28a28ee6701404b6c700d2f6f895bb1fee189d67

MODLIST_SHA1_HASH:  3723fd03f36cd2819b8d3aba6a22b5dc14fe39ad

COMMENT:  
*** "C:\Users\TM\Downloads\Procdump\procdump.exe" -accepteula -ma -j "C:\dumps" 2516 264 02C60000
*** Just-In-Time debugger. PID: 2516 Event Handle: 264 JIT Context: .jdinfo 0x2c60000

NTGLOBALFLAG:  0

PROCESS_BAM_CURRENT_THROTTLED: 0

PROCESS_BAM_PREVIOUS_THROTTLED: 0

APPLICATION_VERIFIER_FLAGS:  0

PRODUCT_TYPE:  1

SUITE_MASK:  272

DUMP_FLAGS:  8000c07

DUMP_TYPE:  3

MISSING_CLR_SYMBOL: 0

ANALYSIS_SESSION_HOST:  WIN-D215DQQE10H

ANALYSIS_SESSION_TIME:  02-06-2018 14:48:06.0391

ANALYSIS_VERSION: 10.0.16299.91 x86fre

MANAGED_CODE: 1

MANAGED_ENGINE_MODULE:  clr

MANAGED_ANALYSIS_PROVIDER:  SOS

MANAGED_THREAD_ID: ca4

THREAD_ATTRIBUTES: 
OS_LOCALE:  DEU

PROBLEM_CLASSES: 

    ID:     [0n301]
    Type:   [@ACCESS_VIOLATION]
    Class:  Addendum
    Scope:  BUCKET_ID
    Name:   Omit
    Data:   Omit
    PID:    [Unspecified]
    TID:    [0xca4]
    Frame:  [0] : fbintl

    ID:     [0n273]
    Type:   [INVALID_POINTER_READ]
    Class:  Primary
    Scope:  DEFAULT_BUCKET_ID (Failure Bucket ID prefix)
            BUCKET_ID
    Name:   Add
    Data:   Omit
    PID:    [Unspecified]
    TID:    [0xca4]
    Frame:  [0] : fbintl

    ID:     [0n91]
    Type:   [@SHUTDOWN]
    Class:  Addendum
    Scope:  DEFAULT_BUCKET_ID (Failure Bucket ID prefix)
            BUCKET_ID
    Name:   Omit
    Data:   Omit
    PID:    [0x9d4]
    TID:    [0xca4]
    Frame:  [0] : fbintl

BUGCHECK_STR:  APPLICATION_FAULT_INVALID_POINTER_READ

PRIMARY_PROBLEM_CLASS:  APPLICATION_FAULT

LAST_CONTROL_TRANSFER:  from 101209e0 to 07314e9c

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
0117ebfc 101209e0 0679bb98 00000000 1008b5c3 fbintl+0x4e9c
0117ec08 1008b5c3 065fe0d0 00000034 1008b8b6 fbembed!Jrd::Collation::destroy+0x10
0117ec14 1008b8b6 0117f03c 0725b3a8 1006bb6f fbembed!CharSetContainer::destroy+0x43
0117ec20 1006bb6f 729e1b02 065f7b98 07286ae0 fbembed!Jrd::Database::destroyIntlObjects+0x26
0117ec88 10070565 065fe0d0 00000001 729e1a4e fbembed!shutdown_database+0x12f
0117ed98 10070986 07286ae0 065fa054 00000001 fbembed!purge_attachment+0x2e5
0117f0ac 10072922 01000000 729e06e2 00001388 fbembed!shutdown_thread+0x276
0117f1cc 1004197b 00001388 729e057a 07420fe0 fbembed!jrd8_shutdown_all+0x152
0117f254 1004286c 00001388 fffffff9 100309f1 fbembed!fb_shutdown+0xdb
0117f260 100309f1 729e05be 07420fe0 10397304 fbembed!`anonymous namespace'::atExitShutdown+0xc
0117f290 10030a7e 729e0596 07420fe0 10397304 fbembed!Firebird::InstanceControl::destructors+0x41
0117f2b8 101b45a5 00000001 00000000 10000000 fbembed!`anonymous namespace'::allClean+0x2e
0117f2cc 101b4694 10000000 00000000 00000001 fbembed!_CRT_INIT+0x167
0117f310 101b4710 10000000 77229ea6 10000000 fbembed!__DllMainCRTStartup+0xb7
0117f318 77229ea6 10000000 00000000 00000001 fbembed!_DllMainCRTStartup+0x1d
0117f338 77229e22 101b46f3 10000000 00000000 ntdll!LdrxCallInitRoutine+0x16
0117f388 7724da28 00000000 00000001 07f1fe02 ntdll!LdrpCallInitRoutine+0x43
0117f428 7724dad1 00000000 00000001 0117f5d4 ntdll!LdrShutdownProcess+0x101
0117f4f0 76b99862 00000000 77e8f3b0 ffffffff ntdll!RtlExitUserProcess+0x81
0117f504 73c42319 00000000 03149506 00000000 kernel32!ExitProcessImplementation+0x12
0117f784 73c42443 00000000 0117f7c8 73697797 mscoreei!RuntimeDesc::ShutdownAllActiveRuntimes+0x34c
0117f790 73697797 0b1ce570 00000000 0361c114 mscoreei!CLRRuntimeHostInternalImpl::ShutdownAllRuntimesThenExit+0x13
0117f7c8 7369771d 00000000 00000000 7f8be000 clr!EEPolicy::ExitProcessViaShim+0x79
0117f9fc 7369c63c 00000000 00000006 0117fa60 clr!SafeExitProcess+0x129
0117fa0c 7369c683 00000000 00000000 01000000 clr!HandleExitProcessHelper+0x63
0117fa20 7369bc2f 0361ccbc 00000000 73671e30 clr!EEPolicy::HandleExitProcess+0x50
0117fa60 73671e4c 0361cc40 00000000 73671e30 clr!_CorExeMainInternal+0x1b1
0117fa9c 73c3e55b 0314982a 76b87b50 73c30000 clr!_CorExeMain+0x4d
0117fad8 73cbbbcc 73cbbb40 73cbbb40 0117fafc mscoreei!_CorExeMain+0x10e
0117fae8 76b87c04 7f8be000 76b87be0 06192ea9 mscoree!_CorExeMain_Exported+0x8c
0117fafc 7723b90f 7f8be000 07f1f16e 00000000 kernel32!BaseThreadInitThunk+0x24
0117fb44 7723b8da ffffffff 772206e8 00000000 ntdll!__RtlUserThreadStart+0x2f
0117fb54 00000000 73cbbb40 7f8be000 00000000 ntdll!_RtlUserThreadStart+0x1b


THREAD_SHA1_HASH_MOD_FUNC:  ea7732901c979b976412f6b7e961e73d1d06677a

THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  6ba60f5ffec2b62e8999d61abcea1781fc579271

THREAD_SHA1_HASH_MOD:  6bb561229e881632e247e46594f9fe2fa9953f0f

FAULT_INSTR_CODE:  b0868b

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  fbintl+4e9c

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: fbintl

IMAGE_NAME:  fbintl.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  5a4f3dbc

STACK_COMMAND:  ~0s ; .ecxr ; kb

FAILURE_BUCKET_ID:  INVALID_POINTER_READ_c0000005_fbintl.dll!Unknown

BUCKET_ID:  APPLICATION_FAULT_INVALID_POINTER_READ_fbintl+4e9c

FAILURE_EXCEPTION_CODE:  c0000005

FAILURE_IMAGE_NAME:  fbintl.dll

BUCKET_ID_IMAGE_STR:  fbintl.dll

FAILURE_MODULE_NAME:  fbintl

BUCKET_ID_MODULE_STR:  fbintl

FAILURE_FUNCTION_NAME:  Unknown

BUCKET_ID_FUNCTION_STR:  Unknown

BUCKET_ID_OFFSET:  4e9c

BUCKET_ID_MODTIMEDATESTAMP:  5a4f3dbc

BUCKET_ID_MODCHECKSUM:  0

BUCKET_ID_MODVER_STR:  2.5.8.27089

BUCKET_ID_PREFIX_STR:  APPLICATION_FAULT_INVALID_POINTER_READ_

FAILURE_PROBLEM_CLASS:  APPLICATION_FAULT

FAILURE_SYMBOL_NAME:  fbintl.dll!Unknown

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/Fewo.exe/19.0.0.0/5a79bf34/fbintl.dll/2.5.8.27089/5a4f3dbc/c0000005/00004e9c.htm?Retriage=1

TARGET_TIME:  2018-02-06T13:45:30.000Z

OSBUILD:  9600

OSSERVICEPACK:  17415

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

OSPLATFORM_TYPE:  x86

OSNAME:  Windows 8.1

OSEDITION:  Windows 8.1 WinNt SingleUserTS

USER_LCID:  0

OSBUILD_TIMESTAMP:  2014-10-29 02:58:22

BUILDDATESTAMP_STR:  141028-1500

BUILDLAB_STR:  winblue_r4

BUILDOSVER_STR:  6.3.9600.17415

ANALYSIS_SESSION_ELAPSED_TIME:  7699

ANALYSIS_SOURCE:  UM

FAILURE_ID_HASH_STRING:  um:invalid_pointer_read_c0000005_fbintl.dll!unknown

FAILURE_ID_HASH:  {d36fbd7c-3cbc-9215-91a9-bcb5a863d227}

Followup:     MachineOwner
---------

Can someone tell my why the error occurs? Thanks in advance!

Update 1: I've tried with Firebird ADO.NET Provider 5.12 too. The error remains the same.

Update 2: The error is reproducable with the following steps:

1) Create a database with a table with a computed index:

CREATE DATABASE 'error_demo.fdb' USER 'SYSDBA' PAGE_SIZE 16384 DEFAULT CHARACTER SET WIN1252 COLLATION WIN1252;
CREATE TABLE OBJEKTE (ID INTEGER, TITLE VARCHAR(10));
CREATE INDEX OBJEKTE_IDX1 ON OBJEKTE COMPUTED BY (lower(title));

2) Create a small C# app using the Firebird ADO.NET Provider 5.12 and query the count from table OBJEKTE and run it on Windows 8.1 (the error doesn't occur if the app is run on Windows 10):

string connstring = "User=SYSDBA;Password=masterkey;Database=error_demo.fdb;DataSource=localhost;Port=3050;Dialect=3;Charset=none;Role=;Connection Lifetime=0;Pooling=true;Packet Size=16384;ServerType=1";
FbConnection connts = new FbConnection(connstring);
connts.Open();

FbCommand cmdts = new FbCommand("select count(*) from objekte", connts);

FbDataReader readerts = cmdts.ExecuteReader();

if (readerts.Read())
{
    int wert = readerts.GetInt32(0);
    readerts.Close();
    readerts.Dispose();
    cmdts.Dispose();
    connts.Close();
    connts.Dispose();
    connts = null;
    return wert;
}
else
{
    readerts.Close();
    readerts.Dispose();
    cmdts.Dispose();
    connts.Close();
    connts.Dispose();
    connts = null;
    return -1;
}

Now, if you close the application, the error occurs. Here's a sample project with a small database: https://www.dropbox.com/s/hakd3zwdxgraq7s/WindowsFormsApp1.zip?dl=0

If you delete the computed index, everything runs well.

anli
  • 515
  • 6
  • 9
  • Have you tried Firebird ado.net provider 5.12? If you can still reproduce it with that, please post a [mcve] to reproduce this. – Mark Rotteveel Feb 06 '18 at 14:11
  • Did you called `fb_shutdown()` before unloading the engine DLL ? – Arioch 'The Feb 06 '18 at 17:45
  • You may also try http://IBProvider.com - but I guess the reason might be related to non-deterministic essence of GC languages. When allocated resources would be freed is random... (yes, I know about IDisp[osable and constructs like using(xxx) do {xxxx}, just they are often forgotten and ignored) – Arioch 'The Feb 06 '18 at 17:49
  • Thanks a lot for your help! I've updated my question with steps to reproduce the problem. – anli Feb 06 '18 at 20:23
  • so, did you call `fb_shutdown` or not ? – Arioch 'The Feb 07 '18 at 08:46
  • @Arioch'The Calling `fb_shutdown` would need to be the responsibility of the driver in this case, iirc. – Mark Rotteveel Feb 07 '18 at 10:07
  • @Arioch'The And in any case, the stacktrace in the analyzed dump clearly shows that the access violation occurs in the call to fb_shutdown. I also checked if using `using` for the resources would make a difference, but it doesn't. – Mark Rotteveel Feb 07 '18 at 10:12
  • And looking closer, `fb_shutdown` is called by the DLL itself when it is notified about the application exit. Interestingly, I tried to reproduce this with Jaybird, and there I don't get an access violation with the same setup. – Mark Rotteveel Feb 07 '18 at 10:31
  • `called by the DLL itself when it is notified about the application exit` AFAIR that is not very reliable and it is better to do so explicitly when using Embedded – Arioch 'The Feb 07 '18 at 11:09
  • `responsibility of the driver in this case` in the ideal world withouyt bugs and oversights. But here we do have some bug and do have to diagnose it first, so making explicit call after terminating FB objects and before unloading DLL can change behavior and give more info, or not – Arioch 'The Feb 07 '18 at 11:11
  • `when it is notified about the application exit.` if u mean `DLLMain` function then it is executed in the half-Windows context with lot of Windows services dysfunctional, so explicit call is a reliable method and DLLMain is the last resort – Arioch 'The Feb 07 '18 at 11:13
  • @Arioch'The Be that as it may, that is what happens here, so `fb_shutdown()` has been called, and it is where the error occurs. I have posted a question to the firebird-devel list, to see if anyone there has an idea. – Mark Rotteveel Feb 07 '18 at 11:19
  • @MarkRotteveel it is interesting that the bug seems only gets triggered by using of functions ( `lower` here ) – Arioch 'The Feb 07 '18 at 12:05
  • 1
    @Arioch'The That is probably because it needs parts from fbintl.dll, which have already have been unloaded by the application exit, or maybe some actions are done in the wrong order. In any case, I now also managed to reproduce it in Jaybird as well if I don't explicitly close the conneciton. – Mark Rotteveel Feb 07 '18 at 12:20
  • "if I don't explicitly close the connection" and there is `connts.Close(); connts.Dispose();` - are those calls just ignored when pooling is enabled ? If so, why can be DLL unloaded while pool was not finalized yet? He tries two different providers, so it does not seem a bug specific to any of them. Anyway I hope @anli would try the same using IBProvider too – Arioch 'The Feb 07 '18 at 15:21
  • @MarkRotteveel if you may be interesting why I call `DLLMain` triggered `fb_shutdown` unreliable by definition - which I am not sure, cause your interests clearly more in higher level managed languages VMs than in low-level OS details, but if it might entertain you you may check articles mentioning DLLMain in Raymond Chen's blog https://social.msdn.microsoft.com/search/en-US?rq=site%3Ablogs.msdn.microsoft.com%2Foldnewthing&rn=oldnewthing&ral=1&query=dllmain – Arioch 'The Feb 08 '18 at 16:14

1 Answers1

2

The problem is caused by the fact that the connection pool is active, and the connections have not been closed before the Firebird Embedded engine is unloaded. I think this is a bug, so I will report it both for Firebird and the ADO.net provider.

To workaround this, you have two options:

  1. Specify Pooling=false in the connection string. The performance overhead of connection creation is marginal for Firebird Embedded connections compared to TCP/IP connections to a remote host, so use of a connection pool doesn't really add that much value.
  2. Alternatively, explicitly call FbConnection.ClearAllPools() before (or on) application exit.

As to the underlying cause: Firebird Embedded tries to clean up after itself on application exit (closing and releasing the unclosed connections), but this appears to fail because one of the DLLs it relies on (probably fbintl.dll) has already been unloaded. As I understand it, Windows will unload DLLs in reverse order of load, ignoring the fact that the earlier loaded DLL might rely on the later loaded one.

Making sure the connections are really closed by cleaning the connection pool (or disabling the connection pool), will already have released the data structures involved.

I have reported ticket DNET-806 to get this fixed in the Firebird ADO.net provider (by explicitly calling the clean up earlier). I also reproduced the same problem in the JDBC driver (for Java) that I maintain, and will fix it there as well.

Mark Rotteveel
  • 100,966
  • 191
  • 140
  • 197