Benedict Singer wrote:
> I was hoping that the casting thing was it, because the
> MiniCCF that creates the CHXHeader does the following:
> 
> *ppUnknown = (IUnknown*)(IHXValues*)(new CHXHeader());
> 
> But all the combinations I've tried of casting and QI'ing
> haven't worked either (although some did change the error a
> bit - I think they messed up the function table instead).
> Also, CHXHeader inherits from CUnknownIMP, not IUnknown directly.

The problem is generally (not always) with the class definition
,not having IUnknow as the first inherited class. Try changing
this:

class CHXHeader : public IHXValues,
                   public IHXValuesRemove
{

private:
...



to

class CHXHeader : public IUnknown,
                   public IHXValues,
                   public IHXValuesRemove
{

private:
...

See if that doesn't fix the problem (be sure the cast looks good
as well).


> 
> Something else I noticed today is that either my debugger
> (VC++ 6.0) is going crazy, or there are multiple defintions of
> IHXValues/CHXHeader stuff floating around (or there are
> align/packing problems). In CHXHeader::CHXHeader, it
> initializes several members to 0x00000000. But when that
> returns to the MiniCCF, the debugger reports one of them as
> 0x00cd0000. Examining the memory itself reveals that nothing
> actually changes, and the 0x00cd0000 value is actually the
> value four bytes in front of the original 0x00000000 value. So
> apparently the debugger thinks that the location of one or
> more member variable moves back 4 bytes between chxpckts.cpp
> and chxminiccf.cpp. 

Seems like it could be casting/inheritance related as well, try
the above fix and see what happens.

--greg.


 > But I think this is what's causing the
> crash, because some of the members of the m_map member var get
> "changed" by that too, so that a SetProperty call after that
> crashes with an access violation. I did find another
> definition of CHXHeader, in old_hxpckts.h/.cpp, but as far as
> I can tell, that's not getting included anywhere. I also
> thought it might be an alignment/packing issue, but changing
> that setting on the exe doesn't do anything. I'll investigate,
> but I don't think anything besides some codecs turns the
> 1-byte alignment setting off. One other thing I noticed was
> that the debugger reports the type of m_map as
> std::template_stuff when in the CHXHeader constructor, but as
> _STL_::template_stuff otherwise; I'm not sure that's
> significant, just something else I noticed. And, of course, I
> may be tackling this from completely the wrong direction. In
> any case, I'm running out of ideas, so any suggestions are
> welcome!
> 
> ---- Original message ----
> 
>>Date: Fri, 05 Aug 2005 10:52:44 -0700
>>From: Greg Wright <gwright at real.com>  
>>Subject: Re: [Helix-client-dev] Release build crashing in
> 
> CreatePlayer  
> 
>>To: Benedict Singer <singerb at uchicago.edu>
>>Cc: helix-client-dev at helixcommunity.org
>>
>>Just a though here, but we have seen crashes like this if a
>>COM object is returned or used after a bad cast. I am a little
>>foggy on what the exact problem was (you can google for it in
>>the helix mailing lists) but it had something to do with casting
>>to IUnknown (I believe) when it was the first class listed in
>>the inheritance list of the object being created. Generally,
>>code in the form:
>>
>>   IUnknown* pFoo = (IUnknown*)new CHXHeader();
>>   return pFoo;
>>
>>   ...
>>
>>   pFoo->SomeFunc()
>>   BOOM!
>>
>>The safe way is to always use QueryInterface to get at the
>>IUnknown. This would be true for other interfaces as well.
>>
>>Can you look for code in your call chain that might be doing
>>some casting like that?
>>
>>--greg.
>>
>>
>>Benedict Singer wrote:
>>
>>>Ok, further investigation has turned up the bug with a fresh
>>>debug build too. The exception I get is:
>>>
>>>First-chance exception in <appname>.exe: 0xC0000005: Access
>>>Violation.
>>>
>>>It happens when trying to set a property in an IHXValues
>>>object. What I observe in the debugger is that some of the
>>>m_Map values inside it appear to be corrupted. However, at
>>>creation time it all looks fine. Further investigation reveals
>>>that when it's created by the MiniCCF, it is a CHXHeader
>>>object. If the pointer to the object is m_pValues, then
>>>examining the contents of m_pValues right after the CCF
>>>returns it shows what look like corrupt contents, while
>>>examining (CHXHeader*)m_pValues looks good, i.e. the CHXHeader
>>>inside the IHXValues looks different than the result of
>>>casting to CHXHeader. The SetProperty call, which eventually
>>>drills down into a lower_bound() call, seems to use the bad
>>>values - specifically, begin() returns a wacky value (seen in
>>>the "corrupt" m_pValues above), and this eventually causes the
>>>crash above. I'm not sure what the root cause of all this is,
>>>however. Inconsistent headers somewhere? I've been trying to
>>>look through the various -cvs mailing lists to see if I can
>>>see a change that might have caused it, since this wasn't
>>>happening earlier this summer, but no luck so far. Anybody
>>>have a better idea of what's happening here than I do?
>>>
>>>---- Original message ----
>>>
>>>
>>>>Date: Thu, 04 Aug 2005 09:55:33 -0700
>>>>From: Greg Wright <gwright at real.com>  
>>>>Subject: Re: [Helix-client-dev] Release build crashing in
>>>
>>>CreatePlayer  
>>>
>>>
>>>>To: Benedict Singer <singerb at uchicago.edu>
>>>>Cc: helix-client-dev at helixcommunity.org
>>>>
>>>>Create a MAP file for the build, then use the debugger, core
>>>>file or whatever to get a hex address of the crash. With
>>>>that HEX address and the map file you can find out what line
>>>>of what source file is crashing. Then you can 'back-up' from
>>>>there with print statements to see what is wrong.
>>>>
>>>>--greg.
>>>>
>>>>
>>>>
>>>>Benedict Singer wrote:
>>>>
>>>>
>>>>>So, with most of the issues now worked out, I'm putting
>>>>>together a release build. Sadly, it crashes (silently) in
>>>>>HXClientEngine::CreatePlayer. Since this is, of course, a
>>>>>release build, I can't use the debugger to work out exactly
>>>>>where! fprintf statements appear to have narrowed it down to
>>>>>somewhere in HXClientEngine::_Initialize(), but that's a much
>>>>>larger function, and I don't fancy putting fprintfs all
>>>>>through that. This is a clean static, release, HEAD,
>>>>>helix-client-all-defines build. A debug build works just fine.
>>>>>Given that I can't see any differences in CreatePlayer() or
>>>>>_Initialize() for a debug vs release build, perhaps it's a
>>>>>problem with loading plugins? Any ideas? Suggestions of how
>>>>>one debugs a release build? Thanks!
>>>>>---------------------
>>>>>Benedict Singer
>>>>>singerb at uchicago.edu
>>>>>http://www.4horsemen.net/ben/
>>>>>
>>>>>_______________________________________________
>>>>>Helix-client-dev mailing list
>>>>>Helix-client-dev at helixcommunity.org
>>>>>
>>>
>>>
> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
> 
>>>---------------------
>>>Benedict Singer
>>>singerb at uchicago.edu
>>>http://www.4horsemen.net/ben/
>>>
>>>_______________________________________________
>>>Helix-client-dev mailing list
>>>Helix-client-dev at helixcommunity.org
>>>
> 
> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
> 
> ---------------------
> Benedict Singer
> singerb at uchicago.edu
> http://www.4horsemen.net/ben/
>