[stlport-bugs] [ stlport-Bugs-1624993 ] crash in locale code on multiprocessor system

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #1624993, was opened at 2006-12-30 18:38
Message generated for change (Comment added) made by workerbee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1624993&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General code
Group: None
>Status: Open
Resolution: Invalid
Priority: 4
Private: No
Submitted By: WorkerBee (workerbee)
Assigned to: Francois Dumont (dums)
Summary: crash in locale code on multiprocessor system

Initial Comment:

* Platform:     Windows XP Professional, Windows 2003 Server
* Hardware:     Centrino Dual Core, Pentium D Dual Core
* Compiler:     Visual C++ 6.0 Service Pack 6
* STLPort:      Version 5.1.0 final version

We have experienced randomly crashes on our production system after switching
from STLport 4.6.2 to 5.1.0.

After some investigation it boils down to being a problem in the locale code
if used in more than one thread on multiprocessor/dual core systems.

Just creating and destroying some locale objects will crash the program on
multiprocessor/dual core systems after a few seconds only if more than one
thread is running.

I have verified the problem with the vanilla STL from Microsofts VC6 which of
course also crashes because it's known to be buggy.

Running the same program under STLport 4.6.2 shows no problems at all, it runs
without any crashes on these systems.

A have provided a simple test case to reproduce the problem.

Could someone please verify that this is a bug ?

Thanks,

Guenter

----------------------------------------------------------------------

>Comment By: WorkerBee (workerbee)
Date: 2007-01-26 08:42

Message:
Logged In: YES 
user_id=1679913
Originator: YES

Well, maybe it is working, but ...
looking at the sources, I found (diff with previous revision)

Line 1747 
1747 	   if (__FindFlag == 0) return -1;
1748 	  	 
1749 	   *lcid = __FndLCID;
1750 	  	 
1751 	   LeaveCriticalSection(&__criticalSection);
1752 	   return 0;

Line 1747 is interesting, you will never leave the
critical section, which causes a deadlock.

This should be fixed ASAP.

BTW: where does void _Locale_init() get called (in a thread safe way) ?

----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-01-12 21:44

Message:
Logged In: YES 
user_id=1096600
Originator: NO

Fix is now available in 5.1 branch, it will be part of 5.1.1. It would be
great if you could check that it is solving your problems.

----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-01-03 22:10

Message:
Logged In: YES 
user_id=1096600
Originator: NO

Hi

What I find the most surprising in this bug report is that you do not
already have this problem with 4.6. I am working on improvements of
localization support and doing so I discovered several multi-threading
issues in Win32 portage. You can check by yourself in
src\c_locale_win32\c_locale_win32.c, you will find several static variables
that are the source of the bugs. You will have undefined behavior in 2
situations:
- use of the time facet in different threads
- creation of 2 locale instances from names in 2 threads at the same time

I will take a closer look to your code sample but as you can see there are
already known issues. The only problem is that I do not have a multicore or
hyperthreaded processor, I hope I will be able to see something on my
simple laptop. You should be able to play with a fixed version in about a
week (it should be in branch STLport.localization).

Bests

----------------------------------------------------------------------

Comment By: WorkerBee (workerbee)
Date: 2007-01-02 13:22

Message:
Logged In: YES 
user_id=1679913
Originator: YES

1. Sorry, but there is no mix of STLport versions.

It is only in the dsp-File because of the way Visual Studio organizes its
"configurations".
The Debug 5_1_0 is a copy of the original Debug configuration, and the
corresponding values have been changed afterwards.

2. I do know that

   while (running)

has no guards.

It's just there to end the threads in a defined way, I don't care when
"running" is read from memory, sooner or later all threads will get the
right value.
Of course, only if they have not crashed in the mean time, which is ALWAYS
the case on our multiprocessor systems.

So, what about the original multiprocessor issue ?

Could you help me, please ?

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-02 09:49

Message:
Logged In: YES 
user_id=615813
Originator: NO

You mix two versions of STLport at least in debug:

...
!ELSEIF  "$(CFG)" == "localetest - Win32 Debug"
...
# ADD BASE ...
# ADD CPP ...  /I "../STLport-4.6.2/stlport" ...
#

!ELSEIF  "$(CFG)" == "localetest - Win32 Debug 5_1_0"

...
# ADD BASE CPP ... /I "../STLport-4.6.2/stlport" ...
# ADD CPP ... /I "../STLport-5.1.0/stlport" ...

...
# ADD BASE LINK32 ... /libpath:"../STLport-4.6.2/lib"
# ADD LINK32 ... /libpath:"../STLport-5.1.0/lib"
...

BTW, code has mistake too:

    while (running) {

don't has any guards. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1624993&group_id=146814