By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,159 Members | 952 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,159 IT Pros & Developers. It's quick & easy.

crash in copy of a list. very simple question.

P: n/a
We encounter a crash every now and then at a client, and now I'm starting to
doubt the fundamentals of life :-)

We have a list of structs.

struct SContactProperty
{
public:
SContactProperty(void) : m_strName(_T("")), m_strValue(_T("")),
m_bHidden(false) {};
tstring m_strName; //The name of the call property
tstring m_strValue; //The value of the call property
bool m_bHidden;
};

if we have 2 variables l1 and l2, both of type list<SContactProperty>, can
one then do simply:
l1=l2;

???
I ask because we put GlobalFlags on so that it crashes at the first memory
misusage. This helped us always in the past to pinpoint the any crash
immediately, but here it leads to such a line.

We used Visual Studio 6 SP6.

Jürgen Devlieghere
Jul 23 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Jürgen Devlieghere wrote:
We encounter a crash every now and then at a client, and now I'm starting to
doubt the fundamentals of life :-)

We have a list of structs.

struct SContactProperty
{
public:
SContactProperty(void) : m_strName(_T("")), m_strValue(_T("")),
m_bHidden(false) {};
tstring m_strName; //The name of the call property
tstring m_strValue; //The value of the call property
What's a 'tstring'? Is that something you cooked up which doesn't manage
its dynamic memory properly?
bool m_bHidden;
};

if we have 2 variables l1 and l2, both of type list<SContactProperty>, can
one then do simply:
l1=l2;

???
I ask because we put GlobalFlags on so that it crashes at the first memory
misusage. This helped us always in the past to pinpoint the any crash
immediately, but here it leads to such a line.
I am not sure I understand what you're trying to say here, but 'tstring'
is very likely to blame.
We used Visual Studio 6 SP6.


Shouldn't matter.

V
Jul 23 '05 #2

P: n/a
Hi,

Sorry, tstring is just std::string in case of ASCII (to have an equivalent
to tchar but for STL).

Jürgen

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:Nh*******************@newsread1.mlpsca01.us.t o.verio.net...
Jürgen Devlieghere wrote:
We encounter a crash every now and then at a client, and now I'm starting
to doubt the fundamentals of life :-)

We have a list of structs.

struct SContactProperty
{
public:
SContactProperty(void) : m_strName(_T("")), m_strValue(_T("")),
m_bHidden(false) {};
tstring m_strName; //The name of the call property
tstring m_strValue; //The value of the call property


What's a 'tstring'? Is that something you cooked up which doesn't manage
its dynamic memory properly?
bool m_bHidden;
};

if we have 2 variables l1 and l2, both of type list<SContactProperty>,
can one then do simply:
l1=l2;

???
I ask because we put GlobalFlags on so that it crashes at the first
memory misusage. This helped us always in the past to pinpoint the any
crash immediately, but here it leads to such a line.


I am not sure I understand what you're trying to say here, but 'tstring'
is very likely to blame.
We used Visual Studio 6 SP6.


Shouldn't matter.

V

Jul 23 '05 #3

P: n/a
Jürgen Devlieghere wrote:
Sorry, tstring is just std::string in case of ASCII (to have an equivalent
to tchar but for STL).
(a) Please don't top-post. Thanks!

(b) If you're sure that 'tstring' is not to blame, there is nothing in
the code you posted to indicate a possible screw-up. Then it is
most likely elsewhere.

Try to create a minimal program (by removing parts of your code that you
think are irrelevant or cannot be the cause of the problem) that still
exhibits the crash you are talking about. If you get a small program that
can do that, post it here. If in the process of reducing your code you
find that some other piece when removed causes the crash to go away, look
at that piece with more care.

Jürgen

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:Nh*******************@newsread1.mlpsca01.us.t o.verio.net...
Jürgen Devlieghere wrote:
We encounter a crash every now and then at a client, and now I'm starting
to doubt the fundamentals of life :-)

We have a list of structs.

struct SContactProperty
{
public:
SContactProperty(void) : m_strName(_T("")), m_strValue(_T("")),
m_bHidden(false) {};
tstring m_strName; //The name of the call property
tstring m_strValue; //The value of the call property


What's a 'tstring'? Is that something you cooked up which doesn't manage
its dynamic memory properly?

bool m_bHidden;
};

if we have 2 variables l1 and l2, both of type list<SContactProperty>,
can one then do simply:
l1=l2;

???
I ask because we put GlobalFlags on so that it crashes at the first
memory misusage. This helped us always in the past to pinpoint the any
crash immediately, but here it leads to such a line.


I am not sure I understand what you're trying to say here, but 'tstring'
is very likely to blame.

We used Visual Studio 6 SP6.


Shouldn't matter.

V

V
Jul 23 '05 #4

P: n/a
Hi,

For all those that suffered and will suffer the same experiences, here the
result.

We used the STL implementation delivered by Microsoft with Visual Studio 6,
which is actually an old Dinkumware implementation, in a multithreaded
environment. Well, it's very simpel. Don't.

Of course we were aware that the STL implementation was not thread-safe. So,
we protected all container actions using semaphores. Well, that's not
enough. The simpel fact that you use std::string from multiple threads will
cause your application to crash in the routines that do string manipulation
/ creation.

Here is a 20 lines example, that will crash within a second, although
nothing is wrong with the code:
#include <string>
#include <time.h>
#include <stdio.h>
#include <windows.h>

unsigned long __stdcall test(void *dummy_p)
{
for (;;)
{
std::string strTest;
for (int i=0;i<10;i++)
{
strTest += "abcdef";
}
}
return 0;
}

void main(void)
{ int i;

DWORD thread_id;

for (i=0;i<100;i++)
CreateThread(NULL,0,test,(void *)i,0,&thread_id);

char buffer[100];
gets(buffer);
}

As you see, only a local stack variable (the string strTest) is manipulated,
so one would think it should not be protected. Well, wrong about that.

Applying a fix available from Dinkumware doesn't help if you compile
"multithreaded dll", since the offending code is then in the dll.

The solution was to move to StlPort. It costed some days to move all our
code, but appart from 1 small issue that is not compatible (the iterator
change if you call delete on a std::set::iterator), we didn't have to change
our code.

Hope to help some people that face the same problem.

Jürgen Devlieghere
Jul 23 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.