access violation due to bad CString copy ctor when porting from VC6 to VC7 (VC++.NET) 
Author Message
 access violation due to bad CString copy ctor when porting from VC6 to VC7 (VC++.NET)

I have a class like this:

class Foo
{
private:
    CString m_sMsg;

public:
    CString GetMsg()
    {
        return(m_sMsg);
    };

Quote:
};

If I then call
    Foo foo;
    CString msg = foo.GetMsg();
I get an ununhandled exception - access violation in the CSimpleCStringT
copy ctor, when it tries to call CloneData(). Going down the call stack for
return(m_sMsg):
say &m_sMsg = 0x7C2EFF24
in the CStringT copy ctor, it shows strSrc = "Bad Ptr" and the address of
strSrc = 0x2EFF2400 (which appears bogus),
in the CSimpleStringT copy ctor, same thing, strSrc = "Bad Ptr" and the
address is again 0x2EFF2400.  In this method, strSrc->GetData() is called,
and this returns bogus memory, and finally calling CloneData() on this
access violates.

In another test, &m_sMsg = 0x01BA71F0, and then in CStringT copy ctor,
&strSrc = 0xBA71F000 ("bad Ptr" again.)  It appears the compiler is
generating bad addresses!  Any ideas?  This code worked fine under VC6 and
previous revs.  I've tried changing various stdafx flag settings and
compiler and linker cmdline settings, but nothing helps.  One would think
upgrading should be easier than this.

thanks!



Mon, 11 Apr 2005 03:01:05 GMT  
 access violation due to bad CString copy ctor when porting from VC6 to VC7 (VC++.NET)
little more info:
if I move the implementation of Foo::GetMsg() from the header to CPP (that
is, out of the class declaration), the problem goes away.  But, I have some
other CString members of this Foo object, and they are getting initialized
to completely bogus values (one is set to NULL - and yes, it's a CString
object not a ptr, others are set to other strange values and if you look in
the de{*filter*} the member object shows up as "Bad Ptr").  This Foo object is a
global object (yuk), but has always worked fine.  I see these bogus values
even before the app crashes, even if I step into the object's constructor, I
see this member CString objects with "Bad Ptr" values.  AHHHHHHHH

Microsoft, please help!!!


Quote:
> I have a class like this:

> class Foo
> {
> private:
>     CString m_sMsg;

> public:
>     CString GetMsg()
>     {
>         return(m_sMsg);
>     };
> };

> If I then call
>     Foo foo;
>     CString msg = foo.GetMsg();
> I get an ununhandled exception - access violation in the CSimpleCStringT
> copy ctor, when it tries to call CloneData(). Going down the call stack
for
> return(m_sMsg):
> say &m_sMsg = 0x7C2EFF24
> in the CStringT copy ctor, it shows strSrc = "Bad Ptr" and the address of
> strSrc = 0x2EFF2400 (which appears bogus),
> in the CSimpleStringT copy ctor, same thing, strSrc = "Bad Ptr" and the
> address is again 0x2EFF2400.  In this method, strSrc->GetData() is called,
> and this returns bogus memory, and finally calling CloneData() on this
> access violates.

> In another test, &m_sMsg = 0x01BA71F0, and then in CStringT copy ctor,
> &strSrc = 0xBA71F000 ("bad Ptr" again.)  It appears the compiler is
> generating bad addresses!  Any ideas?  This code worked fine under VC6 and
> previous revs.  I've tried changing various stdafx flag settings and
> compiler and linker cmdline settings, but nothing helps.  One would think
> upgrading should be easier than this.

> thanks!



Mon, 11 Apr 2005 05:40:44 GMT  
 access violation due to bad CString copy ctor when porting from VC6 to VC7 (VC++.NET)

Quote:
> little more info:
> if I move the implementation of Foo::GetMsg() from the header to CPP (that
> is, out of the class declaration), the problem goes away.  But, I have
some
> other CString members of this Foo object, and they are getting initialized
> to completely bogus values (one is set to NULL - and yes, it's a CString
> object not a ptr, others are set to other strange values and if you look
in
> the de{*filter*} the member object shows up as "Bad Ptr").  This Foo object is
a
> global object (yuk), but has always worked fine.  I see these bogus values
> even before the app crashes, even if I step into the object's constructor,
I
> see this member CString objects with "Bad Ptr" values.  AHHHHHHHH

Can you post a small, compilable example which reproduces the problem(s)
you're experiencing?

-cd [VC++ MVP]



Mon, 11 Apr 2005 07:54:18 GMT  
 access violation due to bad CString copy ctor when porting from VC6 to VC7 (VC++.NET)
I have been trying - if I could, I'd already be on the phone with MS!  It
often is quite difficult to extract the problem out of a big app and get it
into a repro.  No luck yet.

I have seen some bugs on MSDN regarding global variables not being
initialized properly...I think the problem revolves around the
"afxStringManager" global object's creation in relation to my gobal object
in question, but haven't found exact issue yet.  Any help would be
appreciated, thanks



Quote:


> > little more info:
> > if I move the implementation of Foo::GetMsg() from the header to CPP
(that
> > is, out of the class declaration), the problem goes away.  But, I have
> some
> > other CString members of this Foo object, and they are getting
initialized
> > to completely bogus values (one is set to NULL - and yes, it's a CString
> > object not a ptr, others are set to other strange values and if you look
> in
> > the de{*filter*} the member object shows up as "Bad Ptr").  This Foo object
is
> a
> > global object (yuk), but has always worked fine.  I see these bogus
values
> > even before the app crashes, even if I step into the object's
constructor,
> I
> > see this member CString objects with "Bad Ptr" values.  AHHHHHHHH

> Can you post a small, compilable example which reproduces the problem(s)
> you're experiencing?

> -cd [VC++ MVP]



Mon, 11 Apr 2005 23:05:00 GMT  
 access violation due to bad CString copy ctor when porting from VC6 to VC7 (VC++.NET)
You need to initialize m_sMsg. For example, in Foo.cpp:

CFoo::CFoo()
{
 m_sMsg.SetString("Fish");

Quote:
}

--
Donn Trenton
DJ Carter
Visual C++ Team
This posting is provided "AS IS" with no warranties, and confers no rights.


Quote:
> I have a class like this:

> class Foo
> {
> private:
>     CString m_sMsg;

> public:
>     CString GetMsg()
>     {
>         return(m_sMsg);
>     };
> };

> If I then call
>     Foo foo;
>     CString msg = foo.GetMsg();
> I get an ununhandled exception - access violation in the CSimpleCStringT
> copy ctor, when it tries to call CloneData(). Going down the call stack
for
> return(m_sMsg):
> say &m_sMsg = 0x7C2EFF24
> in the CStringT copy ctor, it shows strSrc = "Bad Ptr" and the address of
> strSrc = 0x2EFF2400 (which appears bogus),
> in the CSimpleStringT copy ctor, same thing, strSrc = "Bad Ptr" and the
> address is again 0x2EFF2400.  In this method, strSrc->GetData() is called,
> and this returns bogus memory, and finally calling CloneData() on this
> access violates.

> In another test, &m_sMsg = 0x01BA71F0, and then in CStringT copy ctor,
> &strSrc = 0xBA71F000 ("bad Ptr" again.)  It appears the compiler is
> generating bad addresses!  Any ideas?  This code worked fine under VC6 and
> previous revs.  I've tried changing various stdafx flag settings and
> compiler and linker cmdline settings, but nothing helps.  One would think
> upgrading should be easier than this.

> thanks!



Wed, 13 Apr 2005 02:10:28 GMT  
 access violation due to bad CString copy ctor when porting from VC6 to VC7 (VC++.NET)
ummm...I don't think so! Is that your final answer?



Quote:
> You need to initialize m_sMsg. For example, in Foo.cpp:

> CFoo::CFoo()
> {
>  m_sMsg.SetString("Fish");
> }

> --
> Donn Trenton
> DJ Carter
> Visual C++ Team
> This posting is provided "AS IS" with no warranties, and confers no
rights.



> > I have a class like this:

> > class Foo
> > {
> > private:
> >     CString m_sMsg;

> > public:
> >     CString GetMsg()
> >     {
> >         return(m_sMsg);
> >     };
> > };

> > If I then call
> >     Foo foo;
> >     CString msg = foo.GetMsg();
> > I get an ununhandled exception - access violation in the CSimpleCStringT
> > copy ctor, when it tries to call CloneData(). Going down the call stack
> for
> > return(m_sMsg):
> > say &m_sMsg = 0x7C2EFF24
> > in the CStringT copy ctor, it shows strSrc = "Bad Ptr" and the address
of
> > strSrc = 0x2EFF2400 (which appears bogus),
> > in the CSimpleStringT copy ctor, same thing, strSrc = "Bad Ptr" and the
> > address is again 0x2EFF2400.  In this method, strSrc->GetData() is
called,
> > and this returns bogus memory, and finally calling CloneData() on this
> > access violates.

> > In another test, &m_sMsg = 0x01BA71F0, and then in CStringT copy ctor,
> > &strSrc = 0xBA71F000 ("bad Ptr" again.)  It appears the compiler is
> > generating bad addresses!  Any ideas?  This code worked fine under VC6
and
> > previous revs.  I've tried changing various stdafx flag settings and
> > compiler and linker cmdline settings, but nothing helps.  One would
think
> > upgrading should be easier than this.

> > thanks!



Wed, 13 Apr 2005 06:16:05 GMT  
 access violation due to bad CString copy ctor when porting from VC6 to VC7 (VC++.NET)

Quote:


> > > I have a class like this:

> > > class Foo
> > > {
> > > private:
> > >     CString m_sMsg;

> > > public:
> > >     CString GetMsg()
> > >     {
> > >         return(m_sMsg);
> > >     };
> > > };

> > > If I then call
> > >     Foo foo;
> > >     CString msg = foo.GetMsg();
> > > I get an ununhandled exception - access violation in the
CSimpleCStringT
> > > copy ctor, when it tries to call CloneData(). Going down the call
stack
> > for
> > > return(m_sMsg):
> > > say &m_sMsg = 0x7C2EFF24
> > > in the CStringT copy ctor, it shows strSrc = "Bad Ptr" and the address
> of
> > > strSrc = 0x2EFF2400 (which appears bogus),
> > > in the CSimpleStringT copy ctor, same thing, strSrc = "Bad Ptr" and
the
> > > address is again 0x2EFF2400.  In this method, strSrc->GetData() is
> called,
> > > and this returns bogus memory, and finally calling CloneData() on this
> > > access violates.

> > > In another test, &m_sMsg = 0x01BA71F0, and then in CStringT copy ctor,
> > > &strSrc = 0xBA71F000 ("bad Ptr" again.)  It appears the compiler is
> > > generating bad addresses!  Any ideas?  This code worked fine under VC6
> and
> > > previous revs.  I've tried changing various stdafx flag settings and
> > > compiler and linker cmdline settings, but nothing helps.  One would
> think
> > > upgrading should be easier than this.

Hi,

I am jumping into this thread pretty late but it sounds similar to something
that I was bitten by recently. You mention the addresses in one case above
to be 0x01BA71F0 and then later it is 0xBA71F000. This looks like the
address is off by a byte which usually means an alignment problem.

Are you by chance changing the default alignment to something different?
either in the project settings or by including some other third party header
file? Perhaps try testing that code in a small isolated source file only
including the bare minimum to see if the problem is reproducable. If it
works ok - I would suggest looking a bit closer into what headers you are
using actually do.

For what it is worth - when I started seeing things like this for my
objects - it was because a third party header file was changing the
alignment for its structures but not changing it back. (the header in
question was one of the C++ lotus notes API header files).

Hope this helps.



Wed, 13 Apr 2005 10:09:30 GMT  
 access violation due to bad CString copy ctor when porting from VC6 to VC7 (VC++.NET)
Thanks for the ideas, Brian!  I just checked all the compiler/linker
settings, and it looks like I have everything set to "default" alignment.  I
didn't check thru my headers, as this project unchanged works fine under
VC6, 5, 4, etc.  Is there any place else I should be checking?  I am
suspicious of the project settings in the automatically upgraded VC7
project, as I just noticed it changed my "Release" build to create a DLL
instead of an EXE!!!  I had been working with the debug build, which was
still correctly building an exe (I figured I'd give the release build a try
to see if that worked - and it didn't, it has the same alignment/crash
problems.)  I've spent quite a while trying to make a repro app, but I can't
seem to stumble across the issue.

thanks for your help,
-A


Quote:


> > > > I have a class like this:

> > > > class Foo
> > > > {
> > > > private:
> > > >     CString m_sMsg;

> > > > public:
> > > >     CString GetMsg()
> > > >     {
> > > >         return(m_sMsg);
> > > >     };
> > > > };

> > > > If I then call
> > > >     Foo foo;
> > > >     CString msg = foo.GetMsg();
> > > > I get an ununhandled exception - access violation in the
> CSimpleCStringT
> > > > copy ctor, when it tries to call CloneData(). Going down the call
> stack
> > > for
> > > > return(m_sMsg):
> > > > say &m_sMsg = 0x7C2EFF24
> > > > in the CStringT copy ctor, it shows strSrc = "Bad Ptr" and the
address
> > of
> > > > strSrc = 0x2EFF2400 (which appears bogus),
> > > > in the CSimpleStringT copy ctor, same thing, strSrc = "Bad Ptr" and
> the
> > > > address is again 0x2EFF2400.  In this method, strSrc->GetData() is
> > called,
> > > > and this returns bogus memory, and finally calling CloneData() on
this
> > > > access violates.

> > > > In another test, &m_sMsg = 0x01BA71F0, and then in CStringT copy
ctor,
> > > > &strSrc = 0xBA71F000 ("bad Ptr" again.)  It appears the compiler is
> > > > generating bad addresses!  Any ideas?  This code worked fine under
VC6
> > and
> > > > previous revs.  I've tried changing various stdafx flag settings and
> > > > compiler and linker cmdline settings, but nothing helps.  One would
> > think
> > > > upgrading should be easier than this.

> Hi,

> I am jumping into this thread pretty late but it sounds similar to
something
> that I was bitten by recently. You mention the addresses in one case above
> to be 0x01BA71F0 and then later it is 0xBA71F000. This looks like the
> address is off by a byte which usually means an alignment problem.

> Are you by chance changing the default alignment to something different?
> either in the project settings or by including some other third party
header
> file? Perhaps try testing that code in a small isolated source file only
> including the bare minimum to see if the problem is reproducable. If it
> works ok - I would suggest looking a bit closer into what headers you are
> using actually do.

> For what it is worth - when I started seeing things like this for my
> objects - it was because a third party header file was changing the
> alignment for its structures but not changing it back. (the header in
> question was one of the C++ lotus notes API header files).

> Hope this helps.



Fri, 15 Apr 2005 22:40:56 GMT  
 access violation due to bad CString copy ctor when porting from VC6 to VC7 (VC++.NET)
Well, Brian was correct, it was an alignment issue, except it wasn't from
commandline compiler settings or a *third party* header file changing the
alignment, it was from one of our *own* header files that changed the
alignment!  The problem is, the VC 7.0 compiler changes the way #pragma pack
works!

In one of our headers, we change the packing alignment (using the pragma
pack push functionality), and at the end of the header we change it back
(using the pragma pack pop functionality.)  When compiled under all previous
versions of VC, including VC6SP5, this worked fine.  In VC 7.0, the pragma
pack pop functionality changed, which resulted in the alignment not being
changed back to the default.  This of course caused any class that included
this header to access other objects using the wrong alignment, which of
course resulted in a host of crashes, as described below.

here is an example of the header.h:
----------------------

#pragma pack (push , foo,1)

//declare packing-sensitive structs

#pragma pack (pop , foo,1)

In VC6 and lower, the last line #pragma pack(pop, foo, 1) would restore the
alignment to the alignment active just prior to the

#pragma pack(push, foo, 1) line.  In VC 7.0, the #pragma pack(pop,foo,1)
line changes the packing level to 1.  This functionality is not only
different than previous VC versions, but it also is in conflict with how the
exact same pragma operates in the MIDL compiler (in that doc, the explicitly
state that n - 1 in this case - is ignored if an identifier - 'foo' in this
case - is specified.)

Anyhow, hopefully this functionality gets fixed back to the way it used to
work.  In the mean time, the workaround is easy enough: change the pop line
to be this and it works fine:

 #pragma pack (pop , foo)

Now, I agree that it doesn't make too much sense to be specifying an ignored
n (1 in my case) in the pop-with-identifier syntax anyhow,  but the behavior
change is the real problem - this is code that's been working since 1996,
and the documented behavior changed.

Thanks all for your help, and I hope this wordy msg actually saves someone
some time!

-A


Quote:
> Thanks for the ideas, Brian!  I just checked all the compiler/linker
> settings, and it looks like I have everything set to "default" alignment.
I
> didn't check thru my headers, as this project unchanged works fine under
> VC6, 5, 4, etc.  Is there any place else I should be checking?  I am
> suspicious of the project settings in the automatically upgraded VC7
> project, as I just noticed it changed my "Release" build to create a DLL
> instead of an EXE!!!  I had been working with the debug build, which was
> still correctly building an exe (I figured I'd give the release build a
try
> to see if that worked - and it didn't, it has the same alignment/crash
> problems.)  I've spent quite a while trying to make a repro app, but I
can't
> seem to stumble across the issue.

> thanks for your help,
> -A





> > > > > I have a class like this:

> > > > > class Foo
> > > > > {
> > > > > private:
> > > > >     CString m_sMsg;

> > > > > public:
> > > > >     CString GetMsg()
> > > > >     {
> > > > >         return(m_sMsg);
> > > > >     };
> > > > > };

> > > > > If I then call
> > > > >     Foo foo;
> > > > >     CString msg = foo.GetMsg();
> > > > > I get an ununhandled exception - access violation in the
> > CSimpleCStringT
> > > > > copy ctor, when it tries to call CloneData(). Going down the call
> > stack
> > > > for
> > > > > return(m_sMsg):
> > > > > say &m_sMsg = 0x7C2EFF24
> > > > > in the CStringT copy ctor, it shows strSrc = "Bad Ptr" and the
> address
> > > of
> > > > > strSrc = 0x2EFF2400 (which appears bogus),
> > > > > in the CSimpleStringT copy ctor, same thing, strSrc = "Bad Ptr"
and
> > the
> > > > > address is again 0x2EFF2400.  In this method, strSrc->GetData() is
> > > called,
> > > > > and this returns bogus memory, and finally calling CloneData() on
> this
> > > > > access violates.

> > > > > In another test, &m_sMsg = 0x01BA71F0, and then in CStringT copy
> ctor,
> > > > > &strSrc = 0xBA71F000 ("bad Ptr" again.)  It appears the compiler
is
> > > > > generating bad addresses!  Any ideas?  This code worked fine under
> VC6
> > > and
> > > > > previous revs.  I've tried changing various stdafx flag settings
and
> > > > > compiler and linker cmdline settings, but nothing helps.  One
would
> > > think
> > > > > upgrading should be easier than this.

> > Hi,

> > I am jumping into this thread pretty late but it sounds similar to
> something
> > that I was bitten by recently. You mention the addresses in one case
above
> > to be 0x01BA71F0 and then later it is 0xBA71F000. This looks like the
> > address is off by a byte which usually means an alignment problem.

> > Are you by chance changing the default alignment to something different?
> > either in the project settings or by including some other third party
> header
> > file? Perhaps try testing that code in a small isolated source file only
> > including the bare minimum to see if the problem is reproducable. If it
> > works ok - I would suggest looking a bit closer into what headers you
are
> > using actually do.

> > For what it is worth - when I started seeing things like this for my
> > objects - it was because a third party header file was changing the
> > alignment for its structures but not changing it back. (the header in
> > question was one of the C++ lotus notes API header files).

> > Hope this helps.



Sun, 17 Apr 2005 20:32:05 GMT  
 access violation due to bad CString copy ctor when porting from VC6 to VC7 (VC++.NET)
But let's read on into the next paragraph, where it talks about the POP
functionality (the paragraph you quoted was regarding the PUSH
functionality):
"Each occurrence of a pack pragma with a pop argument retrieves the value at
the top of an internal compiler stack and makes that value the new packing
alignment. If you use pop and the internal compiler stack is empty, the
alignment value is that set from the command-line and a warning is issued.
If you use pop and specify a value for n, that value becomes the new packing
value. If you use pop and specify an identifier, all values stored on the
stack are removed from the stack until a matching identifier is found. The
packing value associated with the identifier is also removed from the stack
and the packing value that existed just before the identifier was pushed
becomes the new packing value. If no matching identifier is found, the
packing value set from the command line is used and a level-one warning is
issued. The default packing alignment is 8."

Note after describing the case for using POP with N, they then go on to
describe the case where POP is used with IDENTIFIER, as:

"...If you use pop and specify an identifier, all values stored on the stack
are removed from the stack until a matching identifier is found. The packing
value associated with the identifier is also removed from the stack and the
packing value that existed just before the identifier was pushed becomes the
new packing value."  In order to reconcile the description of the "POP N"
case (where they say N is the new value) and the "POP identifier case"
(where they say that the packing value just before identifier was pushed is
the new value), I think the best intepretation is to assume the ordering of
the sentences shows the precedence (so N is the new value, unless you have
an identifier, and if you have an indentifier, then N is ignored and the
previously pushed value is the new packing value.) That is, it evals for the
N case, and then evals for the ID case.  Now, another valid way of guessing
about this documentation would be do guess on the implementation, where they
would parse the ID before N.  In that case, once they have a new value (from
the ID in this case), perhaps they would stop parsing.  As it turns out,
pre-VC7, the id DID have precedence.

The doc, however, does not explicitly say what happens if you use BOTH n and
identifier.  So, one continues to puruse the MSDN documentation, to try to
shed more light on the subject.  Eventually, you come across the
documentation for the pragma pack for the MIDL compiler (yes, I know this
isn't the same thing as the C++ compiler, but perhaps it sheds some light.
In this doc, it CLEARLY says

"If pack (pop, id, n) is specified, then n is ignored."

So, seeing this MIDL doc, the actual functionality, along with the ambiguous
doc on the C++ version of the pragma, I personally think the best guess is
that they intended for the pre-VC7 functionality.  Of course, now the VC7
doc for pragma has changed to expliciting say that:

#pragma pack(pop, r1, 2)   // n=2 , stack popped

which does describe the new VC7 behavior, and also decribes conflicting
behavior for the MIDL version.



Quote:
> IMO, this was a bug in VC6 (and before).  VC7+ is now implementing pragma
> pack as described in the documentation (I checked the October 2001 MSDN -
> the last VC6-era version, and the current MSDN).  Examples have been added
> in the newer documentation that clarify this particular case, but even in
> the old documentation, it pretty clearly specifies that the new (VC7+)
> behavior is the correct one.  (I don't have a 1998-era MSDN online to
> check - if they changed the text between 1998 and 2001, well... sorry :)

> "The pragma's argument list is read from left to right. If you use push,
the
> current packing value is stored. If you provide a value for n, that value
> becomes the new packing value. If you specify an identifier, a name of
your
> choosing, the identifier is associated with the new packing value."

> Too bad it took such a painful experience to discover this "fix".

> -cd



> > Well, Brian was correct, it was an alignment issue, except it wasn't
from
> > commandline compiler settings or a *third party* header file changing
the
> > alignment, it was from one of our *own* header files that changed the
> > alignment!  The problem is, the VC 7.0 compiler changes the way #pragma
> pack
> > works!

> > In one of our headers, we change the packing alignment (using the pragma
> > pack push functionality), and at the end of the header we change it back
> > (using the pragma pack pop functionality.)  When compiled under all
> previous
> > versions of VC, including VC6SP5, this worked fine.  In VC 7.0, the
pragma
> > pack pop functionality changed, which resulted in the alignment not
being
> > changed back to the default.  This of course caused any class that
> included
> > this header to access other objects using the wrong alignment, which of
> > course resulted in a host of crashes, as described below.

> > here is an example of the header.h:
> > ----------------------

> > #pragma pack (push , foo,1)

> > //declare packing-sensitive structs

> > #pragma pack (pop , foo,1)

> > In VC6 and lower, the last line #pragma pack(pop, foo, 1) would restore
> the
> > alignment to the alignment active just prior to the

> > #pragma pack(push, foo, 1) line.  In VC 7.0, the #pragma pack(pop,foo,1)
> > line changes the packing level to 1.  This functionality is not only
> > different than previous VC versions, but it also is in conflict with how
> the
> > exact same pragma operates in the MIDL compiler (in that doc, the
> explicitly
> > state that n - 1 in this case - is ignored if an identifier - 'foo' in
> this
> > case - is specified.)

> > Anyhow, hopefully this functionality gets fixed back to the way it used
to
> > work.  In the mean time, the workaround is easy enough: change the pop
> line
> > to be this and it works fine:

> >  #pragma pack (pop , foo)

> > Now, I agree that it doesn't make too much sense to be specifying an
> ignored
> > n (1 in my case) in the pop-with-identifier syntax anyhow,  but the
> behavior
> > change is the real problem - this is code that's been working since
1996,
> > and the documented behavior changed.

> > Thanks all for your help, and I hope this wordy msg actually saves
someone
> > some time!

> > -A



> > > Thanks for the ideas, Brian!  I just checked all the compiler/linker
> > > settings, and it looks like I have everything set to "default"
> alignment.
> > I
> > > didn't check thru my headers, as this project unchanged works fine
under
> > > VC6, 5, 4, etc.  Is there any place else I should be checking?  I am
> > > suspicious of the project settings in the automatically upgraded VC7
> > > project, as I just noticed it changed my "Release" build to create a
DLL
> > > instead of an EXE!!!  I had been working with the debug build, which
was
> > > still correctly building an exe (I figured I'd give the release build
a
> > try
> > > to see if that worked - and it didn't, it has the same alignment/crash
> > > problems.)  I've spent quite a while trying to make a repro app, but I
> > can't
> > > seem to stumble across the issue.

> > > thanks for your help,
> > > -A





> > > > > > > I have a class like this:

> > > > > > > class Foo
> > > > > > > {
> > > > > > > private:
> > > > > > >     CString m_sMsg;

> > > > > > > public:
> > > > > > >     CString GetMsg()
> > > > > > >     {
> > > > > > >         return(m_sMsg);
> > > > > > >     };
> > > > > > > };

> > > > > > > If I then call
> > > > > > >     Foo foo;
> > > > > > >     CString msg = foo.GetMsg();
> > > > > > > I get an ununhandled exception - access violation in the
> > > > CSimpleCStringT
> > > > > > > copy ctor, when it tries to call CloneData(). Going down the
> call
> > > > stack
> > > > > > for
> > > > > > > return(m_sMsg):
> > > > > > > say &m_sMsg = 0x7C2EFF24
> > > > > > > in the CStringT copy ctor, it shows strSrc = "Bad Ptr" and the
> > > address
> > > > > of
> > > > > > > strSrc = 0x2EFF2400 (which appears bogus),
> > > > > > > in the CSimpleStringT copy ctor, same thing, strSrc = "Bad
Ptr"
> > and
> > > > the
> > > > > > > address is again 0x2EFF2400.  In this method,
strSrc->GetData()
> is
> > > > > called,
> > > > > > > and this returns bogus memory, and finally calling CloneData()
> on
> > > this
> > > > > > > access violates.

> > > > > > > In another test, &m_sMsg = 0x01BA71F0, and then in CStringT
copy
> > > ctor,
> > > > > > > &strSrc = 0xBA71F000 ("bad Ptr" again.)  It appears the
compiler
> > is
> > > > > > > generating bad addresses!  Any ideas?  This code worked fine
> under
> > > VC6
> > > > > and
> > > > > > > previous revs.  I've tried changing various stdafx flag
settings
> > and
> > > > > > > compiler and linker cmdline settings, but nothing helps.  One
> > would
> > > > > think
> > > > > > > upgrading should be easier than this.

> > > > Hi,

> > > > I am jumping into this thread pretty late but it sounds similar to
> > > something
> > > > that I was bitten by recently. You mention the addresses in one case
> > above
> > > > to be 0x01BA71F0 and then later it is 0xBA71F000. This looks like
the
> > > > address is off by a byte which usually means an alignment problem.

> > > > Are you

...

read more »



Sun, 17 Apr 2005 23:58:53 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. ASSERT in CString::Mid() when porting from VC6 to VC7

2. ASSERT in CString::Mid() when porting from VC6 to VC7

3. Access Violation when copying a CString in an assignment operator

4. Access Violation when copying a CString in an assignment operator

5. Throw ignores access level of copy ctor and dtor

6. dllimport CString problem from VC7 to VC6

7. CControlBar::m_bAutoDelete=TRUE causes shutdown crash porting from VC6 to VC7

8. Problem while porting VC6 to VC7

9. STL fails while running ported VC6.0 code on VC7

10. Porting from VC6.0 to VC7.0

11. Porting MFC from vc6 to vc7

12. CControlBar::m_bAutoDelete=TRUE causes shutdown crash porting from VC6 to VC7

 

 
Powered by phpBB® Forum Software