Re: Ported to 2005 - Strange variable alignment causing issues

I've got a few more datapoints, though still no answers. (I've also fixed my
posting alias so that I can engage Microsoft ;) ).

Some people may be glad to hear it's not specific to 2005 - I've reproduced
the issue in 2003. However the code works fine in VC6.

The alignment difference seems to be related to 'bool's. I don't care much
about the alignment, of course, but that the code is reading/writing the
wrong address.

I still can not reproduce in a standalone app. The total code is about 1MB
zipped (including resources).

Since this is my first post with the correct email address, I'm going to
repeat some information below for MS:

--
Gonna try here as a starting point. I'm migrating an old Visual C++ 6 project
to VC++ 2005. Just one class is misbehaving - it's member variables are
located at odd addresses (literally, and not aligned to a 4 byte multiple),
and when the code attempts to access them, it typically reads and writes to
the wrong location (it accesses properly aligned addresses), leading to
corruption of the data and stack.

This is with the code copied straight across, and with the code updated so
all the string warnings are updated. If I compile *just* the affected file
(right-click on the file and select 'compile'), then the members are dword
aligned and all is well. However, if I build the entire project, then then
members are NOT aligned and it's not so well.

I have not been able to reproduce in a sample app, and sadly, my application
is pretty large. However, I'd be willing to provide the code to MS for
debugging help.

The class in question is a property page dialog. My class declaration looks
like this:

class DlgWWW : public CPropertyPage
{
    DECLARE_DYNCREATE(DlgWWW)

// Construction
public:
    void UpdateList();
    CString FileList;
    void UpdateOutText();
    CString myIP;
    bool fRoutable;
    DlgWWW();
    ~DlgWWW();

// Dialog Data
    //{{AFX_DATA(DlgWWW)
    enum { IDD = IDD_CFG_WWW };
    CListBox m_List;
    CEdit m_URLText;
    BOOL m_EnableWWW;
    int m_WWWPort;
    int m_MaxConn;
    int m_MaxFileSize;
    int m_WWWTimeout;
    BOOL m_WWWLogEnable;
    //}}AFX_DATA
    char szWWWLogPath[1024];

// Overrides
    // ClassWizard generate virtual function overrides
    //{{AFX_VIRTUAL(DlgWWW)
    protected:
    virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support
    //}}AFX_VIRTUAL

// Implementation
protected:
    // Generated message map functions
    //{{AFX_MSG(DlgWWW)
    virtual BOOL OnInitDialog();
    afx_msg void OnWwwon();
    afx_msg void OnNewfile();
    afx_msg void OnRemovefile();
    afx_msg void OnSetdefault();
    afx_msg void OnSelchangeList1();
    afx_msg void OnKillfocusWwwport();
    afx_msg void OnLogbrowse();
    //}}AFX_MSG
    DECLARE_MESSAGE_MAP()

};

I'm checking the variables right in the constructor, which is where they get
corrupted:

DlgWWW::DlgWWW() : CPropertyPage(DlgWWW::IDD)
{
    if (theApp.WWWPort == 0) {
        theApp.WWWPort=80;
    }

    //{{AFX_DATA_INIT(DlgWWW)
    m_EnableWWW = theApp.EnableWWW;
    m_WWWPort = theApp.WWWPort;
    m_MaxConn = theApp.WWWMaxConn;
    m_MaxFileSize = theApp.MaxFileSize;
    m_WWWTimeout = theApp.WWWTimeout;
    m_WWWLogEnable = theApp.WWWLogEnable;
    //}}AFX_DATA_INIT
.... (etc, it's already broken by this point).

I have addresses like 0x0012dbb5 for m_EnableWWW (int). When the code
actually runs the assignment above, it actually writes to 0x0012dbb8. The
assembly looks like this:

    m_EnableWWW = theApp.EnableWWW;
0046B93E movzx eax,byte ptr [theApp+2A1h (69D351h)]
0046B945 mov ecx,dword ptr [ebp-14h]
0046B948 mov dword ptr [ecx+13Ch],eax
    m_WWWPort = theApp.WWWPort;
0046B94E mov eax,dword ptr [ebp-14h]
0046B951 mov ecx,dword ptr [theApp+264h (69D314h)]
0046B957 mov dword ptr [eax+140h],ecx

This *seems* to be the only file affected, but I'm not certain yet. It
definately seems wrong that the members should live at such odd offsets, but
maybe I'm missing something? I don't think there are any #pragma pack active
and the settings are the default as migrated:

Compiler: /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_VC80_UPGRADE=0x0600"
/D "_MBCS" /Gm /EHsc /RTC1 /MTd /Fp".\Debug/SCWebCam2.pch" /Fo".\Debug/"
/Fd".\Debug/" /FR".\Debug\\" /W3 /nologo /c /ZI /TP /errorReport:prompt

Linker: /OUT:"Debug/SCWebCam3.exe" /INCREMENTAL /NOLOGO /MANIFEST
/MANIFESTFILE:".\Debug\SCWebCam3.exe.intermediate.manifest"
/DELAYLOAD:"OleAcc.dll" /DEBUG /PDB:".\Debug/SCWebCam3.pdb"
/SUBSYSTEM:WINDOWS /MACHINE:X86 /ERRORREPORT:PROMPT nafxcwd.lib shlwapi.lib
jpglibDMTS.lib libpngdmts.lib zlibdmts.lib vfw32.lib rasapi32.lib DelayImp.lib

I'd really like to move up to the new system, any ideas what to look at?

--
Thanks for the ideas, David and Doug.

I verified with #pragma show - the pack level is 8 bytes (does #pragma pack
apply to classes anyway?)

I couldn't find anything odd in the project settings, but as a test I
created a whole new project using the files involved (using File->New
Project from Existing Code), and it exhibited similar symptoms. So I have to
suspect that it's something in my source files. I also rebuilt the libraries
in use (libjpeg, libpng and libz).

I'll continue trying to isolate it.
--