crash in copy of a list. very simple question.

[Jürgen Devlieghere]

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

 

[Victor Bazarov]

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

 

[Jürgen Devlieghere]

Hi,

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

Jürgen

 

[Victor Bazarov]

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

V

 

[Jürgen Devlieghere]

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