Access violation in .NET 4 runtime on NHibernate.ISession.Flush()
695 views
Skip to first unread message
paul_hpfs
Jan 14, 2011, 1:17:54 PM1/14/11
to nhusers
NHibernate 2.1
Oracle.DataAccess 2.112.1.0 x64
Windows 2008 R2
.NET 4
Getting a very intermittent unmanaged exception in the CLR, causing
our application to crash. We have recovered three crash dumps on a
customer production server, unfortunately we have been unable to
reproduce the crash locally. Wondered if anyone was experiencing
something similar?
Following is output from WinDbg
The exception thrown is:
Exception object: 0000000001821228
Exception type: System.ExecutionEngineException
Message: <none>
InnerException: <none>
StackTrace (generated):
<none>
StackTraceString: <none>
HResult: 80131506
0:015> .ecxr
rax=0000000000000018 rbx=0000000021aabeb0 rcx=0000000000000000
rdx=000000005e4ffe10 rsi=0000000000000000 rdi=0000000021aab9c0
rip=000007fef8ac1e1c rsp=0000000021aabf78 rbp=00000000000baea2
r8=0000000000000218 r9=000000005e4ffe10 r10=000000005e4ffe81
r11=00000000000bc9ff r12=000000005e4ffe81 r13=000000005e4ffe80
r14=000000005e4ffeb0 r15=0000000000bc9ffd
iopl=0 nv up ei pl zr na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b
efl=00010244
clr!WKS::gc_heap::find_first_object+0xea:
000007fe`f8ac1e1c f70100000080 test dword ptr [rcx],80000000h ds:
00000000`00000000=????????
the faulting thread:
Thread 15
Current frame: clr!WKS::gc_heap::find_first_object+0xea
Child-SP RetAddr Caller, Callee
0000000021aabf80 000007fef8ac4084 clr!
WKS::gc_heap::mark_through_cards_for_segments+0x1fd, calling clr!
WKS::gc_heap::find_first_object
0000000021aac0f0 000007fef8ac5a17 clr!WKS::gc_heap::relocate_phase
+0x63, calling clr!WKS::gc_heap::mark_through_cards_for_segments
0000000021aac150 000007fef8ac32ae clr!WKS::gc_heap::plan_phase+0x819,
calling clr!WKS::gc_heap::relocate_phase
0000000021aac180 000007fef8a30374 clr!TraceVariableHandles+0xf2,
calling clr!HndScanHandlesForGC
0000000021aac290 000007fef8ac0272 clr!WKS::gc_heap::mark_phase+0x232,
calling clr!SyncBlockCache::GCWeakPtrScan
0000000021aac2c0 000007fef8a332e7 clr!EEJitManager::CleanupCodeHeaps
+0x57, calling clr!CrstBase::Leave
0000000021aac310 000007fef8ac09da clr!WKS::gc_heap::gc1+0xbb, calling
clr!WKS::gc_heap::plan_phase
0000000021aac360 000007fef8ac12d5 clr!WKS::gc_heap::garbage_collect
+0x276, calling clr!WKS::gc_heap::gc1
0000000021aac3b0 000007fef89417c7 clr!DoNDirectCall__PatchGetThreadCall
+0x7b
0000000021aac3c0 000007fef8abf0ae clr!
WKS::gc_heap::try_allocate_more_space+0x15a, calling clr!
_security_check_cookie
0000000021aac3e0 000007fef376866d (MethodDesc 000007fef370b5d0 +0x5d
DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr ByRef)), calling
(MethodDesc 000007feef744660 +0 System.StubHelpers.EEFrame.Pop(Void*,
Void*))
0000000021aac440 000007fef8ac0f8e clr!
WKS::GCHeap::GarbageCollectGeneration+0x14e, calling clr!
WKS::gc_heap::garbage_collect
0000000021aac490 000007fef8abf77e clr!
WKS::gc_heap::try_allocate_more_space+0x25f, calling clr!
WKS::GCHeap::GarbageCollectGeneration
0000000021aac4f0 000007fef3768660 (MethodDesc 000007fef370b5d0 +0x50
DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr ByRef))
0000000021aac520 000007fef376602a (MethodDesc 000007fef370b248 +0x12a
System.Transactions.Transaction.JitSafeGetContextTransaction(System.Transactions.ContextData)),
calling 000007fef37238f0 (stub for
System.Transactions.NativeMethods.CoGetContextToken(IntPtr ByRef))
0000000021aac560 000007fef8abf4ae clr!FastAllocateObject+0x73e,
calling clr!WKS::gc_heap::try_allocate_more_space
0000000021aac5a0 000007fef3766216 (MethodDesc 000007fef370b2a8 +0x106
System.Transactions.Transaction.FastGetTransaction(System.Transactions.TransactionScope,
System.Transactions.ContextData, System.Transactions.Transaction
ByRef)), calling (MethodDesc 000007fef370b248 +0
System.Transactions.Transaction.JitSafeGetContextTransaction(System.Transactions.ContextData))
0000000021aac5e0 000007fef37663e6 (MethodDesc 000007fef370b2c8 +0xe6
System.Transactions.Transaction.get_Current()), calling (MethodDesc
000007fef370b2a8 +0
System.Transactions.Transaction.FastGetTransaction(System.Transactions.TransactionScope,
System.Transactions.ContextData, System.Transactions.Transaction
ByRef))
0000000021aac640 000007fef8a0e658 clr!JIT_NewFast+0xb8, calling clr!
FastAllocateObject
0000000021aac718 000007ff0099f9e4 (MethodDesc 000007ff00a91f08 +0x64
NHibernate.dll!Unknown), calling clr!
JIT_TrialAllocSFastMP_InlineGetThread
0000000021aac7b0 000007fef8a0e5e1 clr!JIT_NewFast+0x41, calling clr!
LazyMachStateCaptureState
0000000021aac7e0 000007ff0099f9e4 (MethodDesc 000007ff00a91f08 +0x64
NHibernate.dll!Unknown), calling clr!
JIT_TrialAllocSFastMP_InlineGetThread
0000000021aac8b0 000007ff00acaed8 (MethodDesc 000007ff00a93310 +0x18
NHibernate.dll!Unknown)
0000000021aac950 000007ff00ce3bad (MethodDesc 000007ff00d36428 +0x8d
NHibernate.dll!Unknown), calling 000007ff00cb2f40
0000000021aac990 000007ff00cdf673 (MethodDesc 000007ff00d344e8 +0x53
NHibernate.dll!Unknown)
0000000021aac9d0 0000000021aaca10 0000000021aaca10, calling
0000000021aaca10
0000000021aaca60 0000000021aacaa0 0000000021aacaa0, calling
0000000021aad29f
0000000021aaca70 000007ff00cda203 (MethodDesc 000007ff003a0470 +0x113
NHibernate.dll!Unknown), calling 000007ff00364830
0000000021aacae0 000007ff00cd9fb3 (MethodDesc 000007ff003a07b8 +0x53
NHibernate.dll!Unknown)
Unfortunately the NHibernate methods are not displayed correctly,
however we have been able to determine that the Garbage collector is
allocating space for new objects, and the crash occurs during this
allocation. We have been able to determine that the exception is
always thrown when the Session.Flush() method is called, although we
have seen the faulting call to the GC within both:
NHibernate.Impl.AbstractSessionImpl.CheckAndUpdateSessionStatus()
and
NHibernate.Util.SequencedHashMap+OrderedEnumerator.get_Current()
Might be similar to this:
http://social.msdn.microsoft.com/Forums/en/clr/thread/33920b39-690c-42c8-b04a-0f1f7176835a
Any help or insight would be much appreciated! Thanks
~ Paul
Oracle.DataAccess 2.112.1.0 x64
Windows 2008 R2
.NET 4
Getting a very intermittent unmanaged exception in the CLR, causing
our application to crash. We have recovered three crash dumps on a
customer production server, unfortunately we have been unable to
reproduce the crash locally. Wondered if anyone was experiencing
something similar?
Following is output from WinDbg
The exception thrown is:
Exception object: 0000000001821228
Exception type: System.ExecutionEngineException
Message: <none>
InnerException: <none>
StackTrace (generated):
<none>
StackTraceString: <none>
HResult: 80131506
0:015> .ecxr
rax=0000000000000018 rbx=0000000021aabeb0 rcx=0000000000000000
rdx=000000005e4ffe10 rsi=0000000000000000 rdi=0000000021aab9c0
rip=000007fef8ac1e1c rsp=0000000021aabf78 rbp=00000000000baea2
r8=0000000000000218 r9=000000005e4ffe10 r10=000000005e4ffe81
r11=00000000000bc9ff r12=000000005e4ffe81 r13=000000005e4ffe80
r14=000000005e4ffeb0 r15=0000000000bc9ffd
iopl=0 nv up ei pl zr na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b
efl=00010244
clr!WKS::gc_heap::find_first_object+0xea:
000007fe`f8ac1e1c f70100000080 test dword ptr [rcx],80000000h ds:
00000000`00000000=????????
the faulting thread:
Thread 15
Current frame: clr!WKS::gc_heap::find_first_object+0xea
Child-SP RetAddr Caller, Callee
0000000021aabf80 000007fef8ac4084 clr!
WKS::gc_heap::mark_through_cards_for_segments+0x1fd, calling clr!
WKS::gc_heap::find_first_object
0000000021aac0f0 000007fef8ac5a17 clr!WKS::gc_heap::relocate_phase
+0x63, calling clr!WKS::gc_heap::mark_through_cards_for_segments
0000000021aac150 000007fef8ac32ae clr!WKS::gc_heap::plan_phase+0x819,
calling clr!WKS::gc_heap::relocate_phase
0000000021aac180 000007fef8a30374 clr!TraceVariableHandles+0xf2,
calling clr!HndScanHandlesForGC
0000000021aac290 000007fef8ac0272 clr!WKS::gc_heap::mark_phase+0x232,
calling clr!SyncBlockCache::GCWeakPtrScan
0000000021aac2c0 000007fef8a332e7 clr!EEJitManager::CleanupCodeHeaps
+0x57, calling clr!CrstBase::Leave
0000000021aac310 000007fef8ac09da clr!WKS::gc_heap::gc1+0xbb, calling
clr!WKS::gc_heap::plan_phase
0000000021aac360 000007fef8ac12d5 clr!WKS::gc_heap::garbage_collect
+0x276, calling clr!WKS::gc_heap::gc1
0000000021aac3b0 000007fef89417c7 clr!DoNDirectCall__PatchGetThreadCall
+0x7b
0000000021aac3c0 000007fef8abf0ae clr!
WKS::gc_heap::try_allocate_more_space+0x15a, calling clr!
_security_check_cookie
0000000021aac3e0 000007fef376866d (MethodDesc 000007fef370b5d0 +0x5d
DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr ByRef)), calling
(MethodDesc 000007feef744660 +0 System.StubHelpers.EEFrame.Pop(Void*,
Void*))
0000000021aac440 000007fef8ac0f8e clr!
WKS::GCHeap::GarbageCollectGeneration+0x14e, calling clr!
WKS::gc_heap::garbage_collect
0000000021aac490 000007fef8abf77e clr!
WKS::gc_heap::try_allocate_more_space+0x25f, calling clr!
WKS::GCHeap::GarbageCollectGeneration
0000000021aac4f0 000007fef3768660 (MethodDesc 000007fef370b5d0 +0x50
DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr ByRef))
0000000021aac520 000007fef376602a (MethodDesc 000007fef370b248 +0x12a
System.Transactions.Transaction.JitSafeGetContextTransaction(System.Transactions.ContextData)),
calling 000007fef37238f0 (stub for
System.Transactions.NativeMethods.CoGetContextToken(IntPtr ByRef))
0000000021aac560 000007fef8abf4ae clr!FastAllocateObject+0x73e,
calling clr!WKS::gc_heap::try_allocate_more_space
0000000021aac5a0 000007fef3766216 (MethodDesc 000007fef370b2a8 +0x106
System.Transactions.Transaction.FastGetTransaction(System.Transactions.TransactionScope,
System.Transactions.ContextData, System.Transactions.Transaction
ByRef)), calling (MethodDesc 000007fef370b248 +0
System.Transactions.Transaction.JitSafeGetContextTransaction(System.Transactions.ContextData))
0000000021aac5e0 000007fef37663e6 (MethodDesc 000007fef370b2c8 +0xe6
System.Transactions.Transaction.get_Current()), calling (MethodDesc
000007fef370b2a8 +0
System.Transactions.Transaction.FastGetTransaction(System.Transactions.TransactionScope,
System.Transactions.ContextData, System.Transactions.Transaction
ByRef))
0000000021aac640 000007fef8a0e658 clr!JIT_NewFast+0xb8, calling clr!
FastAllocateObject
0000000021aac718 000007ff0099f9e4 (MethodDesc 000007ff00a91f08 +0x64
NHibernate.dll!Unknown), calling clr!
JIT_TrialAllocSFastMP_InlineGetThread
0000000021aac7b0 000007fef8a0e5e1 clr!JIT_NewFast+0x41, calling clr!
LazyMachStateCaptureState
0000000021aac7e0 000007ff0099f9e4 (MethodDesc 000007ff00a91f08 +0x64
NHibernate.dll!Unknown), calling clr!
JIT_TrialAllocSFastMP_InlineGetThread
0000000021aac8b0 000007ff00acaed8 (MethodDesc 000007ff00a93310 +0x18
NHibernate.dll!Unknown)
0000000021aac950 000007ff00ce3bad (MethodDesc 000007ff00d36428 +0x8d
NHibernate.dll!Unknown), calling 000007ff00cb2f40
0000000021aac990 000007ff00cdf673 (MethodDesc 000007ff00d344e8 +0x53
NHibernate.dll!Unknown)
0000000021aac9d0 0000000021aaca10 0000000021aaca10, calling
0000000021aaca10
0000000021aaca60 0000000021aacaa0 0000000021aacaa0, calling
0000000021aad29f
0000000021aaca70 000007ff00cda203 (MethodDesc 000007ff003a0470 +0x113
NHibernate.dll!Unknown), calling 000007ff00364830
0000000021aacae0 000007ff00cd9fb3 (MethodDesc 000007ff003a07b8 +0x53
NHibernate.dll!Unknown)
Unfortunately the NHibernate methods are not displayed correctly,
however we have been able to determine that the Garbage collector is
allocating space for new objects, and the crash occurs during this
allocation. We have been able to determine that the exception is
always thrown when the Session.Flush() method is called, although we
have seen the faulting call to the GC within both:
NHibernate.Impl.AbstractSessionImpl.CheckAndUpdateSessionStatus()
and
NHibernate.Util.SequencedHashMap+OrderedEnumerator.get_Current()
Might be similar to this:
http://social.msdn.microsoft.com/Forums/en/clr/thread/33920b39-690c-42c8-b04a-0f1f7176835a
Any help or insight would be much appreciated! Thanks
~ Paul
Rory Plaire
Jan 14, 2011, 3:52:16 PM1/14/11
to nhu...@googlegroups.com
Wow, this is an ugly crash. Given that it appears to be happening when the GC is trying to manage the heap (looks like the mark phase of a collection), I'd guess it is some kind of heap corruption. I'd start trying to eliminate some causes of this, like bad RAM or the Oracle provider (which I'd guess calls into unmanaged code) causing problems.
-r
--
You received this message because you are subscribed to the Google Groups "nhusers" group.
To post to this group, send email to nhu...@googlegroups.com.
To unsubscribe from this group, send email to nhusers+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
paul_hpfs
Feb 18, 2011, 8:29:16 AM2/18/11
to nhusers
An update on this with our findings so far
Oracle.DataAccess 2.112.1.0 isn't supported in .NET4
With Oracle.DataAccess 4.112.1.0 and also 4.112.2.0 the application
crashes continue to happen
We have currently set the following GC flags for our application
<gcServer enabled="false"/>
<gcConcurrent enabled="false"/>
using ODAC 4.112.2.0
and haven't had an application crash since, although it is too early
to conclude that this fixes the issue
Cheers
Paul
On Jan 14, 8:52 pm, Rory Plaire <codekai...@gmail.com> wrote:
> Wow, this is an ugly crash. Given that it appears to be happening when the
> GC is trying to manage the heap (looks like the mark phase of a collection),
> I'd guess it is some kind of heap corruption. I'd start trying to eliminate
> some causes of this, like bad RAM or the Oracle provider (which I'd guess
> calls into unmanaged code) causing problems.
>
> -r
>
> >http://social.msdn.microsoft.com/Forums/en/clr/thread/33920b39-690c-4...
> > .
Oracle.DataAccess 2.112.1.0 isn't supported in .NET4
With Oracle.DataAccess 4.112.1.0 and also 4.112.2.0 the application
crashes continue to happen
We have currently set the following GC flags for our application
<gcServer enabled="false"/>
<gcConcurrent enabled="false"/>
using ODAC 4.112.2.0
and haven't had an application crash since, although it is too early
to conclude that this fixes the issue
Cheers
Paul
On Jan 14, 8:52 pm, Rory Plaire <codekai...@gmail.com> wrote:
> Wow, this is an ugly crash. Given that it appears to be happening when the
> GC is trying to manage the heap (looks like the mark phase of a collection),
> I'd guess it is some kind of heap corruption. I'd start trying to eliminate
> some causes of this, like bad RAM or the Oracle provider (which I'd guess
> calls into unmanaged code) causing problems.
>
> -r
>
>
> > Any help or insight would be much appreciated! Thanks
>
> > ~ Paul
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nhusers" group.
> > To post to this group, send email to nhu...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > nhusers+u...@googlegroups.com<nhusers%2Bunsu...@googlegroups.com >
> > Any help or insight would be much appreciated! Thanks
>
> > ~ Paul
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nhusers" group.
> > To post to this group, send email to nhu...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > .
paul_hpfs
Feb 18, 2011, 10:04:56 AM2/18/11
to nhusers
That should have been:
> Oracle.DataAccess 4.112.2.1 and also 4.112.2.0 versions
> Oracle.DataAccess 4.112.2.1 and also 4.112.2.0 versions
Thomas Bratt
Mar 6, 2012, 6:51:27 AM3/6/12
to nhu...@googlegroups.com
Hi, I work for the same company that paul_hpfs did and thought I would post an update.
It turns out that there was a bug in the .NET garbage collector. We ended up raising a support ticket with Microsoft and there is now a knowledge base article as a result of this (link below):
Thomas
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/nhusers?hl=en.
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/nhusers?hl=en.
Reply all
Reply to author
Forward
0 new messages