HEAP[my.exe]: Invalid Address specified to RtlValidateHeap( 1940000, 1b73290 )
| Author |
Message |
|
Helder R. Melende
#1 / 7
|
 HEAP[my.exe]: Invalid Address specified to RtlValidateHeap( 1940000, 1b73290 ) Using VC++ 6.0 SP4, NT 4.0...
I finally went ahead and made my static libraries DLL's.
I thought this would get rid of my corrupt heap problem,
however, I still have the problem.
I am simply defining an implementation class in DLL one,
and delegating to an instance of it in DLL two:
// ThreadImpl.hpp in DLL1
class ThreadImpl
{
// Do Win32 Thread specific stuff
Quote: };
// Thread.hpp in DLL2 class ThreadImpl; // forward class decl. class Thread { // Default const., copy const., assignment operator, and dest. // because we have an impl_ pointer Thread(); Thread(const Thread&); Thread& operator=(const Thread&); ~Thread(); private: ThreadImpl *impl_; // delegate to this object Quote: };
// Thread.cpp in DLL2 #include "Thread.hpp" #include "ThreadImpl.hpp" // Thread class in DLL2 both new's and delete's an instance
// of a ThreadImpl object...
Thread::Thread() : impl_(new ThreadImpl)
{
Quote: }
Thread::Thread(const Thread& t) : impl_(new ThreadImpl(*t.impl_)) { Quote: }
Thread& operator=(const Thread& t) { if ( &t != this ) { *impl_ = *t.impl_; } return *this; Quote: }
Thread::~Thread() { delete impl_; // RUNTIME ERROR Invalid Address specified to RtlValidateHeap( 1940000, 1b73290 ) Quote: }
Any ideas why I'm getting this invalid address runtime error? Helder
|
| Fri, 04 Apr 2003 03:00:00 GMT |
|
 |
|
Nick Kotarsk
#2 / 7
|
HEAP[my.exe]: Invalid Address specified to RtlValidateHeap( 1940000, 1b73290 ) Well, at a guess, you are still allocating and freeing memory with different
versions of the C run-time library.
In this case allocating with the non-debug C run-time library MSVCRT.DLL and
freeing with the debug C run-time library MSVCRTD.DLL.
See previous threads.
Nick
--
Nick Kotarski
Quote: > Using VC++ 6.0 SP4, NT 4.0... > I finally went ahead and made my static libraries DLL's.
> I thought this would get rid of my corrupt heap problem,
> however, I still have the problem.
> I am simply defining an implementation class in DLL one,
> and delegating to an instance of it in DLL two:
> // ThreadImpl.hpp in DLL1
> class ThreadImpl
> {
> // Do Win32 Thread specific stuff
> };
> // Thread.hpp in DLL2
> class ThreadImpl; // forward class decl.
> class Thread {
> // Default const., copy const., assignment operator, and dest.
> // because we have an impl_ pointer
> Thread();
> Thread(const Thread&);
> Thread& operator=(const Thread&);
> ~Thread();
> private:
> ThreadImpl *impl_; // delegate to this object
> };
> // Thread.cpp in DLL2
> #include "Thread.hpp"
> #include "ThreadImpl.hpp"
> // Thread class in DLL2 both new's and delete's an instance
> // of a ThreadImpl object...
> Thread::Thread() : impl_(new ThreadImpl)
> {
> }
> Thread::Thread(const Thread& t) : impl_(new ThreadImpl(*t.impl_))
> {
> }
> Thread& operator=(const Thread& t)
> {
> if ( &t != this )
> {
> *impl_ = *t.impl_;
> }
> return *this;
> }
> Thread::~Thread()
> {
> delete impl_; // RUNTIME ERROR Invalid Address specified to
> RtlValidateHeap( 1940000, 1b73290 )
> }
> Any ideas why I'm getting this invalid address runtime error?
> Helder
|
| Fri, 04 Apr 2003 03:00:00 GMT |
|
|
|
Helder R. Melende
#3 / 7
|
HEAP[my.exe]: Invalid Address specified to RtlValidateHeap( 1940000, 1b73290 ) Quote:
> Well, at a guess, you are still allocating and freeing memory with different > versions of the C run-time library. > In this case allocating with the non-debug C run-time library MSVCRT.DLL and
> freeing with the debug C run-time library MSVCRTD.DLL.
> See previous threads.
> Nick
Still haven't made any progress, except for the fact that now I have narrowed it down, via the Dependency Walker, to the following culprit (using MSVCRTD.DLL while everything else uses MSVCRT.DLL): MSVCP60D.DLL
Now, I have to somehow figure out what switch or
what setting is causing my code to use this DLL.
This only occurs when I use DLL2. If I compile and link
and exe that uses only the base DLL1, I don't get heap
problems because this MSVCP60D.DLL does not show
up in the Dependency Walker. Oh, boy!
Helder
|
| Fri, 04 Apr 2003 03:00:00 GMT |
|
|
|
Nick Kotarsk
#4 / 7
|
HEAP[my.exe]: Invalid Address specified to RtlValidateHeap( 1940000, 1b73290 ) From MSDN:
Case 2: Sample program test2.cpp
// test2.cpp
#include <iostream>
void main()
{
}
If you build test.cpp using the /ML (or /MLd, for a debug build) compiler
option, your program will link with LIBC.LIB (or LIBCD.LIB, for debug build)
and LIBCP.LIB (or LIBCPD.LIB, for debug build), in addition to other
libraries.
If you build test.cpp using the /MT (or /MTd, for a debug build) compiler
option, your program will link with LIBCMT.LIB (or LIBCMTD.LIB, for debug
build) and LIBCPMT.LIB (or LIBCPMTD.LIB, for debug build), in addition to
other libraries.
If you build test.cpp using the /MD (or /MDd, for a debug build) compiler
option, your program will link with MSVCRT.LIB (or MSVCRTD.LIB, for debug
build) and MSVCPRT.LIB (or MSVCPRTD.LIB, for debug build), in addition to
other libraries. For Visual C++ 6.0, your program will be dependent on
MSVCRT.DLL and MSVCP60.DLL (or MSVCRTD.DLL and MSVCP60D.DLL for debug
build). For Visual C++ 5.0, your program will be dependent on MSVCRT.DLL and
MSVCP50.DLL (or MSVCRTD.DLL and MSVCP50D.DLL for debug build). For Visual
C++ 4.2, your program will be dependent on MSVCRT.DLL (or MSVCRTD.DLL for
debug build) and MSVCPRT.LIB (or MSVCPRTD.LIB, for debug build).
So something uses <iostream> and is compiled using /MDd.
Which causes the debug version of the C run-time library DLL to be used
(MSVCRTD.DLL) and MSVCP60.DLL.
If you change to using /MD you will be using MSVCRT.DLL and MSVCP60.DLL and
your troubles should soon be over.
Nick
--
Nick Kotarski
Quote:
> > Well, at a guess, you are still allocating and freeing memory with
different
> > versions of the C run-time library.
> > In this case allocating with the non-debug C run-time library MSVCRT.DLL
and
> > freeing with the debug C run-time library MSVCRTD.DLL.
> > See previous threads.
> > Nick
> Still haven't made any progress, except for the fact
> that now I have narrowed it down, via the Dependency
> Walker, to the following culprit (using MSVCRTD.DLL
> while everything else uses MSVCRT.DLL):
> MSVCP60D.DLL
> Now, I have to somehow figure out what switch or
> what setting is causing my code to use this DLL.
> This only occurs when I use DLL2. If I compile and link
> and exe that uses only the base DLL1, I don't get heap
> problems because this MSVCP60D.DLL does not show
> up in the Dependency Walker. Oh, boy!
> Helder
|
| Sat, 05 Apr 2003 03:00:00 GMT |
|
|
|
Helder R. Melende
#5 / 7
|
HEAP[my.exe]: Invalid Address specified to RtlValidateHeap( 1940000, 1b73290 ) So, you're saying I have to create non-Debug versions of
my DLL's in order for my EXE's to work? So I can't
step through my DLL's in the de{*filter*}?
Helder
Quote:
> From MSDN: > Case 2: Sample program test2.cpp > // test2.cpp
> #include <iostream>
> void main()
> {
> }
> If you build test.cpp using the /ML (or /MLd, for a debug build) compiler
> option, your program will link with LIBC.LIB (or LIBCD.LIB, for debug build)
> and LIBCP.LIB (or LIBCPD.LIB, for debug build), in addition to other
> libraries.
> If you build test.cpp using the /MT (or /MTd, for a debug build) compiler
> option, your program will link with LIBCMT.LIB (or LIBCMTD.LIB, for debug
> build) and LIBCPMT.LIB (or LIBCPMTD.LIB, for debug build), in addition to
> other libraries.
> If you build test.cpp using the /MD (or /MDd, for a debug build) compiler
> option, your program will link with MSVCRT.LIB (or MSVCRTD.LIB, for debug
> build) and MSVCPRT.LIB (or MSVCPRTD.LIB, for debug build), in addition to
> other libraries. For Visual C++ 6.0, your program will be dependent on
> MSVCRT.DLL and MSVCP60.DLL (or MSVCRTD.DLL and MSVCP60D.DLL for debug
> build). For Visual C++ 5.0, your program will be dependent on MSVCRT.DLL and
> MSVCP50.DLL (or MSVCRTD.DLL and MSVCP50D.DLL for debug build). For Visual
> C++ 4.2, your program will be dependent on MSVCRT.DLL (or MSVCRTD.DLL for
> debug build) and MSVCPRT.LIB (or MSVCPRTD.LIB, for debug build).
> So something uses <iostream> and is compiled using /MDd.
> Which causes the debug version of the C run-time library DLL to be used
> (MSVCRTD.DLL) and MSVCP60.DLL.
> If you change to using /MD you will be using MSVCRT.DLL and MSVCP60.DLL and
> your troubles should soon be over.
> Nick
> --
> Nick Kotarski
> > > Well, at a guess, you are still allocating and freeing memory with
> different
> > > versions of the C run-time library.
> > > In this case allocating with the non-debug C run-time library MSVCRT.DLL
> and
> > > freeing with the debug C run-time library MSVCRTD.DLL.
> > > See previous threads.
> > > Nick
> > Still haven't made any progress, except for the fact
> > that now I have narrowed it down, via the Dependency
> > Walker, to the following culprit (using MSVCRTD.DLL
> > while everything else uses MSVCRT.DLL):
> > MSVCP60D.DLL
> > Now, I have to somehow figure out what switch or
> > what setting is causing my code to use this DLL.
> > This only occurs when I use DLL2. If I compile and link
> > and exe that uses only the base DLL1, I don't get heap
> > problems because this MSVCP60D.DLL does not show
> > up in the Dependency Walker. Oh, boy!
> > Helder
|
| Sat, 05 Apr 2003 03:00:00 GMT |
|
|
|
Helder R. Melende
#6 / 7
|
HEAP[my.exe]: Invalid Address specified to RtlValidateHeap( 1940000, 1b73290 ) I built non-Debug (ReleaseMinSize) versions of both my
DLL's and I still have a problem. I had to set Link->
Ignore libraries: msvcprt
Because I was getting link errors when building the DLL:
libcpmt.lib(ios.obj) : error LNK2005: "public: void __thiscall
already defined in msvcprt.lib(MSVCP60.dll)
Does this have anything to do with my heap problems?
I can't ignore libcpmt, can I?
I've really had it with Windows programming. In the
future I would use the Borland C++ Builder compiler
for Win32 development.
Quote:
> From MSDN: > Case 2: Sample program test2.cpp > // test2.cpp
> #include <iostream>
> void main()
> {
> }
> If you build test.cpp using the /ML (or /MLd, for a debug build) compiler
> option, your program will link with LIBC.LIB (or LIBCD.LIB, for debug build)
> and LIBCP.LIB (or LIBCPD.LIB, for debug build), in addition to other
> libraries.
> If you build test.cpp using the /MT (or /MTd, for a debug build) compiler
> option, your program will link with LIBCMT.LIB (or LIBCMTD.LIB, for debug
> build) and LIBCPMT.LIB (or LIBCPMTD.LIB, for debug build), in addition to
> other libraries.
> If you build test.cpp using the /MD (or /MDd, for a debug build) compiler
> option, your program will link with MSVCRT.LIB (or MSVCRTD.LIB, for debug
> build) and MSVCPRT.LIB (or MSVCPRTD.LIB, for debug build), in addition to
> other libraries. For Visual C++ 6.0, your program will be dependent on
> MSVCRT.DLL and MSVCP60.DLL (or MSVCRTD.DLL and MSVCP60D.DLL for debug
> build). For Visual C++ 5.0, your program will be dependent on MSVCRT.DLL and
> MSVCP50.DLL (or MSVCRTD.DLL and MSVCP50D.DLL for debug build). For Visual
> C++ 4.2, your program will be dependent on MSVCRT.DLL (or MSVCRTD.DLL for
> debug build) and MSVCPRT.LIB (or MSVCPRTD.LIB, for debug build).
> So something uses <iostream> and is compiled using /MDd.
> Which causes the debug version of the C run-time library DLL to be used
> (MSVCRTD.DLL) and MSVCP60.DLL.
> If you change to using /MD you will be using MSVCRT.DLL and MSVCP60.DLL and
> your troubles should soon be over.
> Nick
> --
> Nick Kotarski
> > > Well, at a guess, you are still allocating and freeing memory with
> different
> > > versions of the C run-time library.
> > > In this case allocating with the non-debug C run-time library MSVCRT.DLL
> and
> > > freeing with the debug C run-time library MSVCRTD.DLL.
> > > See previous threads.
> > > Nick
> > Still haven't made any progress, except for the fact
> > that now I have narrowed it down, via the Dependency
> > Walker, to the following culprit (using MSVCRTD.DLL
> > while everything else uses MSVCRT.DLL):
> > MSVCP60D.DLL
> > Now, I have to somehow figure out what switch or
> > what setting is causing my code to use this DLL.
> > This only occurs when I use DLL2. If I compile and link
> > and exe that uses only the base DLL1, I don't get heap
> > problems because this MSVCP60D.DLL does not show
> > up in the Dependency Walker. Oh, boy!
> > Helder
|
| Sat, 05 Apr 2003 03:00:00 GMT |
|
|
|
Nick Kotarsk
#7 / 7
|
HEAP[my.exe]: Invalid Address specified to RtlValidateHeap( 1940000, 1b73290 ) I am not saying that at all.
You can still compile with debug /Zi or /Z7 but what you can't do is use the
debug version of the C run-time library.
If you compile with /Zi and /MD you will create applications and DLLs with
full debugging information present but using the non-debug version of the C
run-time library.
Nick
--
Nick Kotarski
Quote: > So, you're saying I have to create non-Debug versions of > my DLL's in order for my EXE's to work? So I can't > step through my DLL's in the de{*filter*}? > Helder
> > From MSDN:
> > Case 2: Sample program test2.cpp
> > // test2.cpp
> > #include <iostream>
> > void main()
> > {
> > }
> > If you build test.cpp using the /ML (or /MLd, for a debug build)
compiler
> > option, your program will link with LIBC.LIB (or LIBCD.LIB, for debug
build)
> > and LIBCP.LIB (or LIBCPD.LIB, for debug build), in addition to other
> > libraries.
> > If you build test.cpp using the /MT (or /MTd, for a debug build)
compiler
> > option, your program will link with LIBCMT.LIB (or LIBCMTD.LIB, for
debug
> > build) and LIBCPMT.LIB (or LIBCPMTD.LIB, for debug build), in addition
to
> > other libraries.
> > If you build test.cpp using the /MD (or /MDd, for a debug build)
compiler
> > option, your program will link with MSVCRT.LIB (or MSVCRTD.LIB, for
debug
> > build) and MSVCPRT.LIB (or MSVCPRTD.LIB, for debug build), in addition
to
> > other libraries. For Visual C++ 6.0, your program will be dependent on
> > MSVCRT.DLL and MSVCP60.DLL (or MSVCRTD.DLL and MSVCP60D.DLL for debug
> > build). For Visual C++ 5.0, your program will be dependent on MSVCRT.DLL
and
> > MSVCP50.DLL (or MSVCRTD.DLL and MSVCP50D.DLL for debug build). For
Visual
> > C++ 4.2, your program will be dependent on MSVCRT.DLL (or MSVCRTD.DLL
for
> > debug build) and MSVCPRT.LIB (or MSVCPRTD.LIB, for debug build).
> > So something uses <iostream> and is compiled using /MDd.
> > Which causes the debug version of the C run-time library DLL to be used
> > (MSVCRTD.DLL) and MSVCP60.DLL.
> > If you change to using /MD you will be using MSVCRT.DLL and MSVCP60.DLL
and
> > your troubles should soon be over.
> > Nick
> > --
> > Nick Kotarski
> > > > Well, at a guess, you are still allocating and freeing memory with
> > different
> > > > versions of the C run-time library.
> > > > In this case allocating with the non-debug C run-time library
MSVCRT.DLL
> > and
> > > > freeing with the debug C run-time library MSVCRTD.DLL.
> > > > See previous threads.
> > > > Nick
> > > Still haven't made any progress, except for the fact
> > > that now I have narrowed it down, via the Dependency
> > > Walker, to the following culprit (using MSVCRTD.DLL
> > > while everything else uses MSVCRT.DLL):
> > > MSVCP60D.DLL
> > > Now, I have to somehow figure out what switch or
> > > what setting is causing my code to use this DLL.
> > > This only occurs when I use DLL2. If I compile and link
> > > and exe that uses only the base DLL1, I don't get heap
> > > problems because this MSVCP60D.DLL does not show
> > > up in the Dependency Walker. Oh, boy!
> > > Helder
|
| Sat, 05 Apr 2003 03:00:00 GMT |
|
| |
|
