I am making a call to _beginthreadex, so it then does a calloc … and
eventually gets to _heap_alloc_base.
Everything is built using the debug multithreaded library.
A little further information is that this is for memory that is accessed
from both ring 3 and ring 0. It is allocated in ring 3 code.
I am currently preparing a machine with the 2000 debug symbols so I can get
some more information.
Any other suggestions on what to look for?
Thanks!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Eric Lee Steadle
Sent: Friday, July 13, 2001 7:27 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Int 3 while debugging.
I’m curious about this. I assume you’ve seen this behavior in a debugger. Do
you happen to have a stack backtrace of where this happens? (Hopefully, you
have all the debug symbols installed so you can see the entire call chain).
Does your application call heap_alloc_base? I suspect not, but who knows. If
not, what’s the higher function that is calling it.
When does this error occur, at the beginning of your run when the OS is
allocating your heap, or does it happen later after you’ve been running for
a while and your heap has already been allocated?
I’ve seen extrememly weird behavior when I’ve linked libraries compiled with
debug features enabled, with a program where those same debug features are
disabled. The Debug Multi-Threaded and Multi-Threaded libraries have
different, incompatible heap management routines and really perverse bugs
are introduced when a library allocates memory using the Debug libraries and
passes a pointer to that memory to the main program, then the main program
tries to free that memory using non-debug library routines.
(Most memory management libraries have debugging features that keep track of
allocated blocks, sizes of those blocks, etc. They also usually write a
specific set of bytes AFTER the memory that they allocate (e.g. 0xDEADBEEF),
then check that sequence of blocks after you free it. If the expected
sequence isn’t what was written there before it handed you the memory, the
library emits a warning message about possible pointer memory corruption,
believing that you probably wrote past the end of the memory that the heap
routine gave you. Debug versions of the libraries keep extra information at
the beginning of the allocated block so when a block is freed, the routines
can check integrity of the block. However, the retail memory routines don’t
know about this extra bookkeeping information so they report errors when
they realize that the format of the memory block doens’t jive with their
expectations.)
Needless to say, this is a problem, But there should be plenty of errors
dumped to the debug output by the memory management routines if this is the
case. Are you seeing any strange memory errors like this in the debug
output?
In any case, if you’re hitting INT3s inside of the Kernel when your
application runs there’s definitely something wrong and you’re absolutely
right to be concerned about it.
ERX
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@gamry.com
Sent: Thursday, July 12, 2001 1:20 PM
To: NT Developers Interest List
Subject: [ntdev] Int 3 while debugging.
Hi,
When running code on Windows 2k, I get interrupt 3 errors
comming from the
my application. It happens in the NTDLL dll code and occurs
when using
heap_alloc_base. Has anyone had a simular situaltion? If
so, how do you
get around it.
Thanks in advance,
Joe McCloskey
Gamry Instruments, Inc.
xxxxx@gamry.com
You are currently subscribed to ntdev as: xxxxx@spinnakernet.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@gamry.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com