Class Data Alignment Problem in v 7.1

  • Thread starter Thread starter sgraber
  • Start date Start date
S

sgraber

I have encountered a class data alignment issue in Microsoft Visual
Studio .Net 2003 (C++, 7.1). The issue only appears in certain
configurations.

My class is a simple class with no inheritance. The class includes 2
CStringArrays, 3 CStrings, 6 doubles, 2 unsigned chars, a couple of
longs. If I create a copy of the class using 'new CTestClass2', I can
then use the class pointer to call pTestCase2->m_strArray1.SetSize
(10); This works fine. However, if I declare another instance of the
class in another thread => CTestCase2 testCase2; Now the original class
returned by the new CTestClass2 appears to have a data alignment
problem. The vfptr in the m_strArray1 is off by 2 bytes. The first line
in SetSize ASSERT_VALID fails. If I adjust the this pointer by hand,
the SetSize will complete correctly.

Another strange anomaly with this issue is that if I remove all of the
doubles from the class, the SetSize works fine.

The app is a COM app.

Has anyone seen any behavior like this?
 
I have encountered a class data alignment issue in Microsoft Visual
Studio .Net 2003 (C++, 7.1). The issue only appears in certain
configurations.

My class is a simple class with no inheritance. The class includes 2
CStringArrays, 3 CStrings, 6 doubles, 2 unsigned chars, a couple of
longs. If I create a copy of the class using 'new CTestClass2', I can
then use the class pointer to call pTestCase2->m_strArray1.SetSize
(10); This works fine. However, if I declare another instance of the
class in another thread => CTestCase2 testCase2; Now the original class
returned by the new CTestClass2 appears to have a data alignment
problem. The vfptr in the m_strArray1 is off by 2 bytes. The first line
in SetSize ASSERT_VALID fails. If I adjust the this pointer by hand,
the SetSize will complete correctly.

Another strange anomaly with this issue is that if I remove all of the
doubles from the class, the SetSize works fine.

The app is a COM app.

Has anyone seen any behavior like this?
Click to expand...

Yes. It's ALWAYS caused by one or both of two things:

1. Inconsistent compiler options between different modules that were linked
together, particuarly the /Zp command line option.
2. Unmatched #pragma pack() calls - these could be coming from an #include
file so they can be hard to track down.

-cd
 
Back
Top