Crash in dynamic cast in dll code - c++

On Oct 25, 11:23 am, Peeyus...@gmail.com 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*.

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 , Peeyus...@gmail.com 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

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?

Environment Specs-
Win XP, VC++ 6.0

Peeyush81@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.

On Oct 26, 5:41 am, Peeyus...@gmail.com 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.