Heap errors when stressing Automation, _bstr_t, and watching heap blocks 
Author Message
 Heap errors when stressing Automation, _bstr_t, and watching heap blocks

We're having trouble with heap errors occurring when we heavily use a
COM automation server in our product.  By rummaging through previous
usenet postings I've found some evidence that other people have seen
this before, and I've even found one person who has recommended a
possible solution.  The previous postings, however, are sketchy and no
one has ever followed up on the possible solution to confirm that it
really works.

What I'd appreciate is a posting from anyone who has seen this error and
any possible tacks that they might have taken in solving it.  Failing
that, I'd appreciate advice from anyone who could tell how to do a
coherent analysis of the heap during runtime so that I can verify that
any solutions I try are actually solving the problem.

Details:

Putting a heavy load on our automation server, i.e. making lots of calls
over a short period of time, causes one of two types of errors to pop up
in debug:

HEAP[OurApp.exe]: Invalid Address specified to RtlSizeHeap( 130000,
1ec990 )
First-chance exception in OurApp.exe (NTDLL.DLL): 0xC0000005: Access
Violation.
First-chance exception in OurApp.exe (RPCRT4.DLL): 0x8007000E: (no
name).

or

HEAP[OurApp.exe]: Heap block at 1ed7a8 modified at 1ed7c0 past requested
size of 10

Both errors occur with such ferocity that they blow the stack trace
away, leaving me with no calling contexts to sift through.
Occasionally, the first error can be caught by the de{*filter*}.  When we do
catch this error we can only trace as far as the "va_end(argList);" line
of COleDispatchDriver::InvokeHelper, deep in the guts of Microsoft's COM
code.

All I can derive from the above evidence is that something bad is
happening to the heap, and it's not *directly* related to us.  When I
comment out the block of automation calls that seems to be causing the
error, the error just moves to another automation call somewhere down
the line.  This suggests to me that there is some cumulative damage
occurring in the heap and that the error occurs when a certain number of
automation calls have been made.

Back in July, someone in microsoft.public.vc.mfc stated that removing
all usage of _bstr_t solved his problem, but, he didn't say why it
solved the problem.  We make extensive use of _bstr_t, so, before I
propose to my group that we rework all this code I'd like to present
some evidence that this is indeed a solution.  To gather that evidence I
need to look at the heap, and I'm having a heck of a time doing that.
I've messed around with CMemoryState and _CrtCheckMemory and I can't
figure out how they're supposed to help me with this.  I've read in MSDN
that you can read memory dump info into Excel and use pivot tables to
analyze the heap, but I can't figure out how to do this.  We even have a
couple of developers sumo wrestling with a copy of Insure++ to get a
look at the heap, but, we're not having much luck with that.  What we
need is someone to tell us a quick and dirty way to get a detailed look
at the heap.

thanks

Andrew Bono



Mon, 19 Aug 2002 03:00:00 GMT  
 
 [ 1 post ] 

 Relevant Pages 

1. HEAP[dllhost.exe]: HEAP: Free Heap block 1e32c28 modified at 1e32dc4 after it was freed

2. HEAP error: Free heap block xxx mdofied at xxx

3. "Heap block" error

4. "Heap block" error

5. Binomial heaps / Fibonacci heaps

6. (ATL) COM dll heap vs CRT heap

7. watch the heap size

8. Invalid heap signature for heap

9. Heap watching for memory leaks.

10. Decoding a .bmp image from heap to heap

11. Heap block

12. problem with malloc in VC++6 SP1 (small block heap handler)

 

 
Powered by phpBB® Forum Software