Issue Details (XML | Word | Printable)

Key: DNET-582
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Jiri Cincura
Reporter: Hennadii Zabula
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
.NET Data provider

Random bug in finalizing DbCommands

Created: 19/Dec/14 02:18 PM   Updated: 21/Feb/17 07:47 AM
Component/s: ADO.NET Provider
Affects Version/s: 4.5.2.0
Fix Version/s: 5.8.0.0

Environment: Windows Server 2008 R2. firebird 2.5.3 x64 embedded
Issue Links:
Relate
 


 Description  « Hide
Several times I've experienced randomly reproduced bug. It has some different symptoms: OOM, unhandled crash and so on.
But all this times I had the same stack:
000000001b56edb0 00000000773a186a [FaultingExceptionFrame: 000000001b56edb0]
000000001b56f300 000007fe9a9920b0 FirebirdSql.Data.FirebirdClient.FbCommand.Release() [*\FirebirdSql.Data.FirebirdClient\FirebirdClient\FbCommand.cs @ 821]
000000001b56f340 000007fe9a9a47f5 FirebirdSql.Data.FirebirdClient.FbCommand.Dispose(Boolean) [*\FirebirdSql.Data.FirebirdClient\FirebirdClient\FbCommand.cs @ 384]
000000001b56f3a0 000007fef71cc8da System.ComponentModel.Component.Finalize()
000000001b56f798 000007fef9479d56 [DebuggerU2MCatchHandlerFrame: 000000001b56f798]

It is locally built library so I'll provide lines referred above:
FbCommand.cs @ 821
            if (this.connection != null && this.connection.State == ConnectionState.Open)
            {
                this.connection.InnerConnection.RemovePreparedCommand(this);
            }
FbCommand.cs @ 384
           try
                    {
                        // Release any unmanaged resources
                        this.Release();

I've added crutch to the FbCommand.Release method as in other places, just handle exception without any code. But I think it is not the best way to fix it.

                   try
                    {
                        // old code
                    }
                    catch // added
                    {
                    }
                    finally
                    {
                        base.Dispose(disposing);
                    }

Don't you think that catching swallowing exceptions in dispose methods is a bad way to handle errors?

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Hennadii Zabula added a comment - 19/Dec/14 02:51 PM - edited
Forgot to mention the exception, that occurs

Exception object: 00000000039081f0
Exception type: System.NullReferenceException
Message: Object reference not set to an instance of an object.
InnerException: <none>
StackTrace (generated):
    SP IP Function
    000000001B56F300 000007FE9A9920B0 FirebirdSql_Data_FirebirdClient!FirebirdSql.Data.FirebirdClient.FbCommand.Release()+0x40
    000000001B56F340 000007FE9A9A47F5 FirebirdSql_Data_FirebirdClient!FirebirdSql.Data.FirebirdClient.FbCommand.Dispose(Boolean)+0x65
    000000001B56F3A0 000007FEF71CC8DA System_ni!System.ComponentModel.Component.Finalize()+0x2a

StackTraceString: <none>
HResult: 80004003

Hennadii Zabula added a comment - 19/Dec/14 02:54 PM
my suggestion, that connection.InnerConnection is null or/and disposed when finalization performs.
I think that the lifetime of the FbCommand is longer than it should be.

Hennadii Zabula added a comment - 08/Nov/15 02:53 PM
Reproduced again in our production environment after several days working.
Version: 4.8.1.1

Jiri Cincura added a comment - 02/Jan/16 09:34 AM
Does this only happen in embedded or also when running against server?