[stlport-bugs] [ stlport-Bugs-1624993 ] crash in locale code on multiprocessor system
Brought to you by:
complement
From: SourceForge.net <no...@so...> - 2007-01-26 21:12:09
|
Bugs item #1624993, was opened at 2006-12-30 18:38 Message generated for change (Comment added) made by dums 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: Pending 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: Francois Dumont (dums) Date: 2007-01-26 22:12 Message: Logged In: YES user_id=1096600 Originator: NO I agree I have been a little distracted on this point. Thanks for having report it before 5.1.1 release. About _Locale_init, you have the source so I am sure you know where it is called. It is associated to Standard iostreams initialization (cout, cin, ...). It is compiler/platform dependent but you can consider that it is called at library load time, even before you enter main, so at a necessarily thread safe moment. ---------------------------------------------------------------------- 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 |