Re: c++/4248: reinterpret_cast in template

[Nathan Sidwell <nathan at codesourcery dot com>]

"Denkhaus, Volker" wrote:
> let me try to explain in more detail. Also I will insert the interesting
> lines of the code and the machine code as well to explain what I think is
> going wrong.
thanks, but there is insufficient information. I'll explain through the
remainder of the email. The only way I can help you further is with the 
preprocessed source code that actually compiled the program. Not bits of it.

> 
> >From what I can see, it looks like the vtable is OK. The pointer passed to
> that function (pv) can be examined like this:
> (gdb) print pv
> $1 = (void *) 0x8072bc8
How do you know this actually points to a CComObject<RsCommon::CRSComponentShellDummy>
dummy object?

> 
> The pointer this->mpOwner has the same value after the cast statement:
> (gdb) print this->m_pOwner
> $2 = (CComObject<RsCommon::CRSComponentShellDummy> *) 0x8072bc8
> 
> Now I examine the address:
> 
> (gdb) x /16x 0x8072bc8
> 0x8072bc8:      0x40cae020      0x40ce5d00      0x00000000      0xffffffff
> 0x8072bd8:      0xffffffff      0xffffffff      0xffffffff      0x00000000
> 0x8072be8:      0x706d742f      0x424c542f      0x33646266      0x504d542e
> 0x8072bf8:      0x00000000      0x00000000      0x00000000      0x00000000
> 
> The first value at 0x8072bc8 I assume is the pointer to the vtable, i.e.
> 0x40cae020. Now I do an examine of this address:
It looks like *a* vtable. with multiple inheritance there is more than

> --> This is the code for calling the AddRef function:
> 6.) mov    0x34(%esi),%edx  // now we have the value of this->m_pOwner in
> edx, i.e. 0x8072bc8
> 7.) add    $0x20,%edx        // Why add 0x20 to this here ??
> 8.) mov    (%edx),%eax       // Going to the address, i.e. the vtable which
> is wrong now because of the 0x20 before
to get to a secondary vtable. That is pulling a non-vtable pointer out of your
object dump though. Have you done something like cast to a base class of
CComObject<RsCommon::CRSComponentShellDummy> to get the pv value, and then
assumed that reinterpret case will get back to the complete object?

I'm sorry, whenever I've seen the symptoms you provide, the cause has always
been
a) version skew as I initially said
b) illformed casts within a class heirarchy 

it is possible it's a compiler problem, but I cannot tell without the source.

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org