Home > Archive > VC STL > January 2006 > Is there something basic that I have missed on the upgrade to VS2005?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Is there something basic that I have missed on the upgrade to VS2005?
|
|
|
| I have quite a bit of legacy code that initialises stl containers from c
arrays thus ...
const char* test_data[] = { "test01", "test02", "test03", "test04",
"test05" };
typedef std::vector<std::string> vec_strings;
vec_strings v1(test_data, test_data +
sizeof(test_data)/sizeof(test_data[0]));
If you cut/paste this code into a new project it will compile, build and run
just fine.
However there are a number of projects that I have upgraded from VS2003.Net.
These projects compile/build just fine, but when container ctor is called I
get a debug assertion in the stl code "ITERATOR LIST CORRUPTED!"
This is the code from xutility that is asserting (*_Pnext == 0) and I have
not a clue why.
void __CLR_OR_THIS_CALL _Orphan_me()
{ // cut ties with parent
if (_Mycont != 0 && _Mycont->_Myfirstiter != _IGNORE_MYITERLIST)
{ // adopted, remove self from list
_Iterator_base **_Pnext =
(_Iterator_base **)&_Mycont->_Myfirstiter;
while (*_Pnext != 0 && *_Pnext != this)
_Pnext = &(*_Pnext)->_Mynextiter;
if (*_Pnext == 0)
_DEBUG_ERROR("ITERATOR LIST CORRUPTED!");
*_Pnext = _Mynextiter;
_Mycont = 0;
}
}
The call stack looks like this ...
msvcp80d.dll!std::_Debug_message() + 0x21 bytes
hyperion_demo.exe!std::_Iterator_base::_Orphan_me() Line 178 + 0x17 bytes
C++
hyperion_demo. exe!std::_Iterator_base::~_Iterator_base
() Line 151 C++
hyperion_demo.exe!std::_Bidit<std::basic_string<char,std::char_traits<char>,std::allocator<char>
td::basic_string<char,std::char_traits<char>,std::allocator<char> > const
*,std::basic_string<char,std::char_traits<char>,std::allocator<char> > const
&>::~_Bidit<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>,int,std::basic_string<char,std::char_traits<char>,std::allocator<char> >
const *,std::basic_string<char,std::char_traits<char>,std::allocator<char> >
const &>() + 0x2b bytes C++
hyperion_demo.exe!std::_Tree<std::_Tset_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char>[color=darkred]
>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>
>,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char>
hyperion_demo.exe!std::_Tree<std::_Tset_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char>[color=darkred]
>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>
>,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char>
hyperion_demo.exe!std::_Tree<std::_Tset_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char>[color=darkred]
>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>
>,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char>
std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
_Val="scenario") Line 630 + 0x49 bytes C++
hyperion_demo.exe!std::set<std::basic_string<char,std::char_traits<char>,std::allocator<char>[color=darkred]
>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>
>,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>::set<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>
>,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char>
_Last=0x004a56f8) Line 111 + 0x35 bytes C++
hyperion_demo.exe!hfm_parser::parse(const
std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
eas="Scenario = 1 ...
I am getting this same assertion in other contexts which worked just fine
before I upgraded.
Anyone know what might be going on here?
My hunch is that the visual studio project has not been upgraded to work
correctly with the newer version of the stl but I really don't know where to
begin looking.
Andy
| |
| Igor Tandetnik 2006-01-09, 11:10 pm |
| "Andy" <arb70sok@hotmail.com> wrote in message
news:eEOBd3RFGHA.3176@TK2MSFTNGP12.phx.gbl
> I have quite a bit of legacy code that initialises stl containers
> from c arrays thus ...
>
> const char* test_data[] = { "test01", "test02", "test03", "test04",
> "test05" };
> typedef std::vector<std::string> vec_strings;
>
> vec_strings v1(test_data, test_data +
> sizeof(test_data)/sizeof(test_data[0]));
>
> If you cut/paste this code into a new project it will compile, build
> and run just fine.
>
> However there are a number of projects that I have upgraded from
> VS2003.Net. These projects compile/build just fine, but when container
> ctor is
> called I get a debug assertion in the stl code "ITERATOR LIST
> CORRUPTED!"
> This is the code from xutility that is asserting (*_Pnext == 0) and I
> have not a clue why.
I don't think your initialization method causes the problem. You are
doing something illegal elsewhere, like using an iterator after it has
been invalidated (e.g. by modifying the underlying container).
STL shipped with VC8 catches such errors in debug build. VC7.1 does not
have this debugging mode, and you could get away with some violations.
The code is still buggy even if it appears to work, of course.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
| |
|
| > I don't think your initialization method causes the problem. You are doing
> something illegal elsewhere, like using an iterator after it has been
> invalidated (e.g. by modifying the underlying container).
I am afraid there is no question about the fact that it is the
initialization is causing the problem.
You can see that from the call stack. Unfortunately it is probably hard to
pick it out. This is the relevant line.
hyperion_demo.exe!std::set<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::set<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::less
<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > ><char const * *>(const char * * _First=0x004a56c4, const char * *_Last=0x004a56f8) Line 111 + 0
x35 bytes C++I may very well be doing something illegal elsewhere but this problem iswith the initialisation of a set and I get exactly the same error if Iswitch container to a vector or list.Andy"Igor Tandetnik" <itandetnik@mvps.org> wrote in messagenews
:eKC$H$RFGHA.740@TK2MSFTNGP12.phx.gbl...> "Andy" <arb70sok@hotmail.com> wrote in message> news:eEOBd3RFGHA.3176@TK2MSFTNGP12.phx.gbl>> I have quite a bit of legacy code that initialises stl containers>> from c arrays thus ...>>>> const char* test_data[] =
{ "test01", "test02", "test03", "test04",>> "test05" };>> typedef std::vector<std::string> vec_strings;>>>> vec_strings v1(test_data, test_data +>> sizeof(test_data)/sizeof(test_data[0]));>>>> If you cut/paste this code into a new project it will compile
, build>> and run just fine.>>>> However there are a number of projects that I have upgraded from>> VS2003.Net. These projects compile/build just fine, but when containerctor is>> called I get a debug assertion in the stl code "ITERATOR LIST CORRUPTED!">>
This is the code from xutility that is asserting (*_Pnext == 0) and I>> have not a clue why.>> I don't think your initialization method causes the problem. You are doingsomething illegal elsewhere, like using an iterator after it has beeninvalidated (e.g
. by modifying the underlying container).>> STL shipped with VC8 catches such errors in debug build. VC7.1 does nothave this debugging mode, and you could get away with some violations. Thecode is still buggy even if it appears to work, of course.> --> Wi
th best wishes,> Igor Tandetnik>> With sufficient thrust, pigs fly just fine. However, this is notnecessarily a good idea. It is hard to be sure where they are going to land,and it could be dangerous sitting under them as they fly overhead. -- RFC1925>
| |
|
| I have reposted this as the formatting seemed to get a bit screwed up on
previous post.
> I don't think your initialization method causes the problem. You are doing
> something illegal elsewhere, like using an iterator after it has been
> invalidated (e.g. by modifying the underlying container).
I am afraid there is no question about the fact that it is the
initialization is causing the problem.
You can see that from the call stack. Unfortunately it is probably hard to
pick it out. This is the relevant line.
hyperion_demo.exe!std::set<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char>>>,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >>::set<std::basic_string<char,std::char_traits<char>,std::allocator<char>>,std::less<std
::basic_string<char,std::char_traits<char>,std::allocator<char> >>,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > ><char const * *>(const char * * _First=0x004a56c4, const char **_Last=0x004a56f8)I may very well be d
oing something illegal elsewhere but this problem iswiththe initialisation of a set (the original code I posted used a vector).I get exactly the same error if I switch container to a vector or list.Andy"Igor Tandetnik" <itandetnik@mvps.org> wrote in messa
genews:eKC$H$RFGHA.740@TK2MSFTNGP12.phx.gbl...> "Andy" <arb70sok@hotmail.com> wrote in message> news:eEOBd3RFGHA.3176@TK2MSFTNGP12.phx.gbl>> I have quite a bit of legacy code that initialises stl containers>> from c arrays thus ...>>>> const char* test_da
ta[] = { "test01", "test02", "test03", "test04",>> "test05" };>> typedef std::vector<std::string> vec_strings;>>>> vec_strings v1(test_data, test_data +>> sizeof(test_data)/sizeof(test_data[0]));>>>> If you cut/paste this code into a new project it will c
ompile, build>> and run just fine.>>>> However there are a number of projects that I have upgraded from>> VS2003.Net. These projects compile/build just fine, but when containerctor is>> called I get a debug assertion in the stl code "ITERATOR LIST CORRUPT
ED!">> This is the code from xutility that is asserting (*_Pnext == 0) and I>> have not a clue why.>> I don't think your initialization method causes the problem. You are doingsomething illegal elsewhere, like using an iterator after it has beeninvalidate
d (e.g. by modifying the underlying container).>> STL shipped with VC8 catches such errors in debug build. VC7.1 does nothave this debugging mode, and you could get away with some violations. Thecode is still buggy even if it appears to work, of course.>
--> With best wishes,> Igor Tandetnik>> With sufficient thrust, pigs fly just fine. However, this is notnecessarily a good idea. It is hard to be sure where they are going to land,and it could be dangerous sitting under them as they fly overhead. -- RF
C1925>
| |
| Ulrich Eckhardt 2006-01-09, 11:10 pm |
| Andy wrote:
>
> I am afraid there is no question about the fact that it is the
> initialization is causing the problem.
> You can see that from the call stack. Unfortunately it is probably hard
> to pick it out. This is the relevant line.
I could see from your original posting that there are two 'char const**'
involved somewhere in the call, but it's hard to tell because the
stacktrace you posted there is already broken, something must have gone
wrong with cut'n'paste.
Anyway, the fist step is cleaning up that stacktrace, the "line" you dumped
here was far from readable. Also, since we're talking about the
standardlibrary, remove all 'std::'. Further, since it involves the vanilla
std::string, replace all basic_string<...> with just string. I don't want
to harass you, but that is simply what is necessary to read these things
and I would do the same.
I could see that it involves initialising a set<string> with two 'char
const**' and that it fails at the end of the called insert() method. Could
you confirm that and create a minimal testcase?
Uli
| |
| Carl Daniel [VC++ MVP] 2006-01-09, 11:10 pm |
| Andy wrote:
> I have quite a bit of legacy code that initialises stl containers
> from c arrays thus ...
>
> const char* test_data[] = { "test01", "test02", "test03", "test04",
> "test05" };
> typedef std::vector<std::string> vec_strings;
>
> vec_strings v1(test_data, test_data +
> sizeof(test_data)/sizeof(test_data[0]));
>
> If you cut/paste this code into a new project it will compile, build
> and run just fine.
>
> However there are a number of projects that I have upgraded from
> VS2003.Net. These projects compile/build just fine, but when container
> ctor is
> called I get a debug assertion in the stl code "ITERATOR LIST CORRUPTED!"
> This is the code from xutility that is asserting (*_Pnext == 0) and I
> have not a clue why.
From the error message you posted, it appears that you're initializing a
std::set, not a std::vector. But this:
#include <string>
#include <set>
int main()
{
const char* test_data[] = { "test01", "test02", "test03",
"test04","test05" };
typedef std::set<std::string> set_strings;
set_strings s1(test_data, test_data + sizeof(char*));
}
compiles just fine, so there's more to it than you've posted.
Please produce and post a minimal example that reproduces the error. Odds
are that you'll discover what's wrong in the course of producing that
minimal repro case.
-cd
| |
|
| "Ulrich Eckhardt" wrote
> Anyway, the fist step is cleaning up that stacktrace, the "line" you
> dumped
> here was far from readable. Also, since we're talking about the
> standardlibrary, remove all 'std::'. Further, since it involves the
> vanilla
> std::string, replace all basic_string<...> with just string. I don't want
> to harass you, but that is simply what is necessary to read these things
> and I would do the same.
Fair comment the stack strace line that shows the set ctor call cleansed as
you
suggest
set<string,less<string >,allocator<string > >::set<string,less<string
>,allocator<string > >
<char const * *>(const char * * _First=0x004a56c4, const char * *
_Last=0x004a56f8)
I am the one looking for help! It is up to me to do everything possible to
help you (or others)
help me! I should have done all that without your prompt.
Andy
"Ulrich Eckhardt" <eckhardt@satorlaser.com> wrote in message
news:2vaa93-5p6.ln1@satorlaser.homedns.org...[color=darkred]
> Andy wrote:
>
> I could see from your original posting that there are two 'char const**'
> involved somewhere in the call, but it's hard to tell because the
> stacktrace you posted there is already broken, something must have gone
> wrong with cut'n'paste.
> Anyway, the fist step is cleaning up that stacktrace, the "line" you
> dumped
> here was far from readable. Also, since we're talking about the
> standardlibrary, remove all 'std::'. Further, since it involves the
> vanilla
> std::string, replace all basic_string<...> with just string. I don't want
> to harass you, but that is simply what is necessary to read these things
> and I would do the same.
>
> I could see that it involves initialising a set<string> with two 'char
> const**' and that it fails at the end of the called insert() method. Could
> you confirm that and create a minimal testcase?
>
> Uli
>
| |
|
| >> compiles just fine, so there's more to it than you've posted.
Indeed I acknowledged that from the outset!
This only happens on legacy code that has been upgraded from VS2003.Net.
> Please produce and post a minimal example that reproduces the error. Odds
What do you suggest?
I have tried to create a 'simple' example that has only the original code in
VS2003,
upgraded that to VS2005 and it all works hunky dory.
This problem seems reluctant to surface with simple examples.
I suspect that I am doing something wrong and I suspect that it is in the
project configuration.
I also suspect that it has occurred as part of the upgrade process to VS2005
as this code ran
fine before the upgrade to VS2005.
Andy
"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam>
wrote in message news:e11hvDTFGHA.984@tk2msftngp13.phx.gbl...
> Andy wrote:
>
> From the error message you posted, it appears that you're initializing a
> std::set, not a std::vector. But this:
>
> #include <string>
> #include <set>
>
> int main()
> {
> const char* test_data[] = { "test01", "test02", "test03",
> "test04","test05" };
> typedef std::set<std::string> set_strings;
>
> set_strings s1(test_data, test_data + sizeof(char*));
> }
>
> compiles just fine, so there's more to it than you've posted.
>
> Please produce and post a minimal example that reproduces the error. Odds
> are that you'll discover what's wrong in the course of producing that
> minimal repro case.
>
> -cd
>
>
| |
| Stephen Howe 2006-01-09, 11:10 pm |
| > I also suspect that it has occurred as part of the upgrade process to
VS2005
> as this code ran
> fine before the upgrade to VS2005.
Maybe not.
Compiler upgrades sometimes expose latent bugs in code. It may not have been
"fine" before.
Each generation round the compiler is more stringent in terms of error
checking so it may well have picked up something that was not correct before
but you got away with it for any earlier version.
It is a possibility.
Stephen Howe
| |
| Carl Daniel [VC++ MVP] 2006-01-09, 11:10 pm |
| Andy wrote:
>
> Indeed I acknowledged that from the outset!
Actually, you didn't. Your example used std:::vector.
> This only happens on legacy code that has been upgraded from
> VS2003.Net.
>
> What do you suggest?
> I have tried to create a 'simple' example that has only the original
> code in VS2003,
> upgraded that to VS2005 and it all works hunky dory.
>
> This problem seems reluctant to surface with simple examples.
> I suspect that I am doing something wrong and I suspect that it is in
> the project configuration.
> I also suspect that it has occurred as part of the upgrade process to
> VS2005 as this code ran
> fine before the upgrade to VS2005.
More likely is that the code was never "just fine", but rather just happened
to compile due to a bug in the earlier compiler.
As for producing a minimal example, start with a file that doesn't compile.
Copy it and all suspected dependencies to a new project and verify that you
can recreate the error.
Next, start removing parts of the file that you believe unrelated. Keep
cutting it down until you get the smallest version that you can that fails
to compile. It's tedious, but it's the only way.
-cd
| |
|
| > Actually, you didn't. Your example used std:::vector.
Quote from my original post ...
>If you cut/paste this code into a new project it will compile, build and
>run just fine.
You are correct that my OP did use standard vector and in the example I
posted later I referred to std::set.
Apologies. That must have been very confusing.
However the runtime error occurs when initialising a std::vector, std::set
or a std::list from raw pointers.
> As for producing a minimal example, start with a file that doesn't
> compile. Copy it and all suspected dependencies to a new project and
> verify that you can recreate the error.
All my code compiles just fine. This is a runtime issue.
However I take your point. Thank you.
Andy
"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam>
wrote in message news:uqtyIuTFGHA.3488@TK2MSFTNGP10.phx.gbl...
> Andy wrote:
>
> Actually, you didn't. Your example used std:::vector.
>
>
> More likely is that the code was never "just fine", but rather just
> happened to compile due to a bug in the earlier compiler.
>
> As for producing a minimal example, start with a file that doesn't
> compile. Copy it and all suspected dependencies to a new project and
> verify that you can recreate the error.
>
> Next, start removing parts of the file that you believe unrelated. Keep
> cutting it down until you get the smallest version that you can that fails
> to compile. It's tedious, but it's the only way.
>
> -cd
>
>
| |
|
| I found out what is causing this problem, but I do not understand why!
In the precompiled header for the upgraded projct there was a #import
statement.
#import "<3rd party dll>"
When I removed that everything worked correctly again.
Thanks to Carl for his hack away until you unconver the problem strategy
that got me here.
Fortunately I think that I can either do without the 3rd party library or
hide it away somewhere where it will cause less trouble.
Still have not got a clue why this should have caused the problem though.
Andy
"Andy" <arb70sok@hotmail.com> wrote in message
news:eEOBd3RFGHA.3176@TK2MSFTNGP12.phx.gbl...
>I have quite a bit of legacy code that initialises stl containers from c
>arrays thus ...
>
> const char* test_data[] = { "test01", "test02", "test03", "test04",
> "test05" };
> typedef std::vector<std::string> vec_strings;
>
> vec_strings v1(test_data, test_data +
> sizeof(test_data)/sizeof(test_data[0]));
>
> If you cut/paste this code into a new project it will compile, build and
> run just fine.
>
> However there are a number of projects that I have upgraded from
> VS2003.Net.
> These projects compile/build just fine, but when container ctor is called
> I get a debug assertion in the stl code "ITERATOR LIST CORRUPTED!"
> This is the code from xutility that is asserting (*_Pnext == 0) and I have
> not a clue why.
>
> void __CLR_OR_THIS_CALL _Orphan_me()
> { // cut ties with parent
>
> if (_Mycont != 0 && _Mycont->_Myfirstiter != _IGNORE_MYITERLIST)
>
> { // adopted, remove self from list
>
> _Iterator_base **_Pnext =
>
> (_Iterator_base **)&_Mycont->_Myfirstiter;
>
> while (*_Pnext != 0 && *_Pnext != this)
>
> _Pnext = &(*_Pnext)->_Mynextiter;
>
> if (*_Pnext == 0)
>
> _DEBUG_ERROR("ITERATOR LIST CORRUPTED!");
>
> *_Pnext = _Mynextiter;
>
> _Mycont = 0;
>
> }
>
> }
>
> The call stack looks like this ...
>
> msvcp80d.dll!std::_Debug_message() + 0x21 bytes
> hyperion_demo.exe!std::_Iterator_base::_Orphan_me() Line 178 + 0x17 bytes
> C++
> hyperion_demo. exe!std::_Iterator_base::~_Iterator_base
() Line 151 C++
>
> hyperion_demo.exe!std::_Bidit<std::basic_string<char,std::char_traits<char>,std::allocator<char>
> td::basic_string<char,std::char_traits<char>,std::allocator<char> > const
> *,std::basic_string<char,std::char_traits<char>,std::allocator<char> >
> const
> &>::~_Bidit<std::basic_string<char,std::char_traits<char>,std::allocator<char>
> const *,std::basic_string<char,std::char_traits<char>,std::allocator<char>
>
> hyperion_demo.exe!std::_Tree<std::_Tset_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>
> hyperion_demo.exe!std::_Tree<std::_Tset_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char>
>
> hyperion_demo.exe!std::_Tree<std::_Tset_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char>
> std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
> _Val="scenario") Line 630 + 0x49 bytes C++
>
> hyperion_demo.exe!std::set<std::basic_string<char,std::char_traits<char>,std::allocator<char>
> _Last=0x004a56f8) Line 111 + 0x35 bytes C++
> hyperion_demo.exe!hfm_parser::parse(const
> std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
> eas="Scenario = 1 ...
>
> I am getting this same assertion in other contexts which worked just fine
> before I upgraded.
> Anyone know what might be going on here?
> My hunch is that the visual studio project has not been upgraded to work
> correctly with the newer version of the stl but I really don't know where
> to begin looking.
>
> Andy
>
| |
| Brian Muth 2006-01-09, 11:10 pm |
| That would make me suspect a name collision problem.
Are you using a "using namespace std" statement? If so, I would try removing
it, and prefixing the STL calls with the appropriate "std::" name scope.
Brian
| |
| Carl Daniel [VC++ MVP] 2006-01-09, 11:10 pm |
| "Andy" <arb70sok@hotmail.com> wrote in message
news:OhLjHJUFGHA.524@TK2MSFTNGP09.phx.gbl...
>
> All my code compiles just fine. This is a runtime issue.
D'oh! I had compile-time error on the brain! Sorry for the noise.
-cd
| |
|
| > That would make me suspect a name collision problem.
I also think that this is the most likely cause of the problem or some evil
macro hackery, possibly in the 3rd pary library.
> Are you using a "using namespace std" statement?
No. I tend to always prefix with std::. I did however remove all the std::
prefix from a diagnostic in an earlier post just to make it easier to read.
Andy
"Brian Muth" <bmuth@mvps.org> wrote in message
news:O4uEIPWFGHA.3984@TK2MSFTNGP14.phx.gbl...
> That would make me suspect a name collision problem.
>
> Are you using a "using namespace std" statement? If so, I would try
> removing it, and prefixing the STL calls with the appropriate "std::" name
> scope.
>
> Brian
>
| |
|
| > Don't worry, it will undoubtedly come back sooner or later and you'll
I do worry! This is really horrible. I do now have a 'reproducible'
example of the problem and I intend to do some more fishing to get to the
bottom of it. I am inclined to think that Brian's suggestion in the
previous post is correct and that there is a name collision problem.
Introducing the 3rd party library may have introduced some, possibly illegal
(as in non standard) definition, which I suspect is clashing with something
that is being used in the stl code.
When I have got more details I will post here again.
Thanks for the interest.
Andy
"Pete Becker" <petebecker@acm.org> wrote in message
news:2v-dncovKLoAcF_eRVn-vQ@giganews.com...
> Andy wrote:
>
> Don't worry, it will undoubtedly come back sooner or later and you'll get
> another chance to hunt it down. Problems that go away by themselves come
> back by themselves.
>
> Your description of the problem sounds like a memory overwrite, typically
> caused by writing through a bad pointer, running off the end of allocated
> space, or freeing the same memory block more than once. Those things often
> don't cause problems immediately, but, instead, cause problems that show
> up in other places, and move when you change unrelated code. If that's
> what's happening, the import statement didn't cause the problem. Removing
> it simply made the symptom that you were seeing go away.
>
> --
>
> Pete Becker
> Dinkumware, Ltd. (http://www.dinkumware.com)
| |
| Ulrich Eckhardt 2006-01-10, 4:16 am |
| Andy wrote:
> I found out what is causing this problem, but I do not understand why!
> In the precompiled header for the upgraded projct there was a #import
> statement.
>
> #import "<3rd party dll>"
>
> When I removed that everything worked correctly again.
OK, what kind of library is that? I ask because you generally can't mix C++
code compiled with two different compilers or even compiler versions(!).
So, if that lib uses std::string and your code uses std::string, they might
in fact be referring to two different binary representations thereof. You
will need to recompile that lib, too, then.
Uli
| |
|
| > OK, what kind of library is that?
It is a COM import library and as far as I can see is not relatied to the
STL code I am using.
The only objects I am passing to the library are ones that are defined in
its header.
It is not using any STL types.
Contrary to my previous post I am having a lot of trouble precisely
isolating this problem.
Andy
"Ulrich Eckhardt" <eckhardt@satorlaser.com> wrote in message
news:r28c93-oa8.ln1@satorlaser.homedns.org...
> Andy wrote:
>
>
> OK, what kind of library is that? I ask because you generally can't mix
> C++
> code compiled with two different compilers or even compiler versions(!).
> So, if that lib uses std::string and your code uses std::string, they
> might
> in fact be referring to two different binary representations thereof. You
> will need to recompile that lib, too, then.
>
> Uli
>
| |
| Stephen Howe 2006-01-10, 7:24 pm |
| > #import "<3rd party dll>"
Qn 1) Was that ADO?
Qn 2) Did you do a full recompile when you experienced your problems? There
has been the odd occasion when the precompiled header hs been out-of-sync
with compilation options. A full recompile re-syncs everything again.
Stephen Howe
| |
| Stephen Howe 2006-01-10, 7:24 pm |
| > It is a COM import library and as far as I can see is not relatied to the
> STL code I am using.
It is not ADO by any chance?
With ADO you do have to "rename" EOF (End of File) as it confuses EOF as
defined in <stdio.h> with its own EOF definition.
I say "rename" in quotes because the #import statement supports renaming of
symbols to prevent name collision - we took advantage of this to rename
"EOF" in ADO as "ADOEOF".
Now it may be that you need to do the same.
If you have used #import for this 3rd party DLL, see if you can find files
on your hard disk
3rdpartyname.TLH
3rdpartyname.TLI
They are the header include and inline functions generated by #import.
Searching through these in an editor might give you an idea as to what
collides.
Stephen Howe
| |
|
| > Qn 1) Was that ADO?
No
> Qn 2) Did you do a full recompile when you experienced your problems?
> There has been the odd occasion when the precompiled header hs been
> out-of-sync with compilation options. A full recompile re-syncs everything
> again.
Yes
This problem originally occurred when upgrading a solution/project from
VS.Net 2003.
If I create a new solution/project in VS2005 and then add my original source
all seems to be OK.
I think that something is going wrong during the upgrade process, but just
don't have time to track the issue down at the moment.
I do intend to return to this issue and hopefully pin it down more
precisely, as no doubt others will hit it sooner or later.
I promise that when I have something more useful to say on the issue I will
post my findings here!
Andy
"Stephen Howe" <sjhoweATdialDOTpipexDOTcom> wrote in message
news:eJJUFMgFGHA.1288@TK2MSFTNGP09.phx.gbl...
>
> Qn 1) Was that ADO?
>
> Qn 2) Did you do a full recompile when you experienced your problems?
> There has been the odd occasion when the precompiled header hs been
> out-of-sync with compilation options. A full recompile re-syncs everything
> again.
>
> Stephen Howe
>
|
|
|
|
|