Crash in dynamic cast in dll code

[Peeyush81]

Hi All,
I am trying to invoke methods in c++ code in two ways, one by
compiling the calling code with the called code and running it
standalone, other by making a dll of the called code and then calling
it. First case works fine but in the 2nd case, I encounter a crash
at the following line
CThread* ct = &CThread::GetCurrentThread();
TEventHandler* eh = dynamic_cast< TEventHandler* >( ct );

Any hints why the crash occurs?

Thanks,
Peeyush

[Jonathan Lane]

On Oct 25, 11:23 am, [e-mail] wrote:

Hi All,
I am trying to invoke methods in c++ code in two ways, one by
compiling the calling code with the called code and running it
standalone, other by making a dll of the called code and then calling
it. First case works fine but in the 2nd case, I encounter a crash
at the following line
CThread* ct = &CThread::GetCurrentThread();
TEventHandler* eh = dynamic_cast< TEventHandler* >( ct );

Any hints why the crash occurs?

The most obvious thing is that you're dynamic casting to a pointer. If
that fails it returns NULL. Do you test eh for being NULL as you
always should with bare pointers?
That's the most obvious culprit, to me at least. What's the difference
in the code that's doing this in the local code and in the DLL? Can a
CThread* be safely cast to a TEventHandler*.

[qinghu.liao]

Make sure that you compile the DLL with RTTI support. otherwise there
is no
RTTI info to support the dynamic_cast and then it will crash.

On 10 25 , 6 23 , [e-mail] wrote:

Hi All,
I am trying to invoke methods in c++ code in two ways, one by
compiling the calling code with the called code and running it
standalone, other by making a dll of the called code and then calling
it. First case works fine but in the 2nd case, I encounter a crash
at the following line
CThread* ct = &CThread::GetCurrentThread();
TEventHandler* eh = dynamic_cast< TEventHandler* >( ct );

Any hints why the crash occurs?

Thanks,
Peeyush

[Peeyush81]

Thanks for the prompt responses,
Jonathan,
The pointer is not null and assigned a valid address.( I checked in
debug)
I cannot find any differences between the two ways of invoking the
code.

Liao,
I have RTTI check enabled now. Now it does not crash at that line but
at the line next to it.
If I continue ,it repeats this arbitrary behavior at random lines,
even at
simple String assignments.

TString fddevName = "DAL";

Could it be a problem of stack
overflow bacause of insufficient memory to the program when running in
dll mode?

[Peeyush81]

Environment Specs-
Win XP, VC++ 6.0

[Ron Natalie]

Pe*******@gmail.com wrote:

even at
simple String assignments.

TString fddevName = "DAL";

Could it be a problem of stack
overflow bacause of insufficient memory to the program when running in
dll mode?

What the * is a TString? "DAL" is not a string, it's an array
of char[].

The other Visual Studio gotcha is to make sure all your DLL's are
compiled with the same C++ runtimes (see the CODE GENERATION TAB)
or to be darned sure that you do all your memory allocation and
deallocation in the same DLL (i.e., no inlined allocations in the
headers!)>

Your best bet is to take this off-topic qustion over to one
of the groups that has "microsoft" in its name.

[Jonathan Lane]

On Oct 26, 5:41 am, [e-mail] wrote:

Thanks for the prompt responses,
Jonathan,
The pointer is not null and assigned a valid address.( I checked in
debug)
I cannot find any differences between the two ways of invoking the
code.

Liao,
I have RTTI check enabled now. Now it does not crash at that line but
at the line next to it.
If I continue ,it repeats this arbitrary behavior at random lines,
even at
simple String assignments.

TString fddevName = "DAL";

Could it be a problem of stack
overflow bacause of insufficient memory to the program when running in
dll mode?

I would doubt it's run out of memory to be honest. If it's crashing at
a random point later then you've obviously already corrupted the heap.
I did find, a while back, a technique to log all allocations and de-
allocations. Try googling for something like that to see where you're
corrupting the heap.

Otherwise, as Ron Natalie suggests it could be down to using different
runtimes in the different components. Check that in the project
settings. Also make sure that you're linking against the same version
of the libraries that supply these types. I've seen errors similar to
this where different versions of the STL are used by the third party
vendor and STL types are passed on the command line.

Failing that, the types you have are all MS types so try a MS C++
newsgroup.