Eric Lemings wrote:
file stdcxx/trunk/src/locale_global.cpp:
...
56 setlocale (_RWSTD_LC_ALL, rhs.name ().c_str ());
...
setlocale() is not a MTS function, is it? From what I see,
it looks like std::locale::global() is being called from
two threads with the same rhs object.
You're right, that does look like a bug in our library. We should
guard the call to setlocale().
Martin
From the Solaris setlocale(3C) man page:
"NOTES
It is unsafe for any thread to change locale (by calling
setlocale() with a non-null locale argument) in a mul-
tithreaded application while any other thread in the appli-
cation is using any locale-sensitive routine. To change
locale in a multithreaded application, setlocale() should be
called prior to using any locale-sensitive routine. Using
setlocale() to query the current locale is safe and can be
used anywhere in a multithreaded application except when
some other thread is changing locale."
Brad.
-----Original Message-----
From: Eric Lemings (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 02, 2008 4:39 PM
To: Eric Lemings
Subject: [jira] Commented: (STDCXX-811) [Solaris Threads]
SIGSEGV in 22.locale.statics.mt.cpp
[
https://issues.apache.org/jira/browse/STDCXX-811?page=com.atla
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focus
edCommentId=12584863#action_12584863 ]
Eric Lemings commented on STDCXX-811:
-------------------------------------
Here's a stack trace where the test is failing, just for the record.
{noformat}
[EMAIL PROTECTED] tests]$ dbx ./22.locale.statics.mt core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message
7.6' in your .dbxrc
Reading 22.locale.statics.mt
dbx: warning: core object name "22.locale.stati" matches
object name "22.locale.statics.mt" within the limit of 14.
assuming they match
core file header read successfully
Reading ld.so.1
...
Reading [EMAIL PROTECTED]
[EMAIL PROTECTED] ([EMAIL PROTECTED]) terminated by signal SEGV (no mapping at
the fault address)
0xffffffff7f60dbb8: defrag+0x0078: ld [%g5 + 16], %o5
Current function is std::locale::global
56 setlocale (_RWSTD_LC_ALL, rhs.name ().c_str ());
(dbx) where
current thread: [EMAIL PROTECTED]
[1] defrag(0xffffffff59200000, 0x59200160,
0xffffffff7f72cb18, 0xffffffff59200010, 0xffffffff592000e0,
0x4f383835392d3520), at 0xffffffff7f60dbb8
[2] get_lcinterface(0xffffffff7f72c1b8, 0xffffffff7f72c370,
0xffffffff7e3fb708, 0x0, 0x2000, 0xffffffff7f627728), at
0xffffffff7f60e1b8
[3] informrtld(0x21e0, 0x2000, 0xffffffff7e95e988,
0xffffffff7eae6000, 0x158954, 0x101010101010101), at
0xffffffff7e98d6fc
[4] _setlocale(0xffffffff7c9052f0, 0xffffffff7e9dbc7e, 0x6,
0xffffffff7c905230, 0x2000, 0xffffffff7eaf00b0), at 0xffffffff7e98d458
=>[5] std::locale::global(rhs = STRUCT), line 56 in
"locale_global.cpp"
[6] test_global(_ARG1 = 0xffffffff7fffe9b8), line 95 in
"22.locale.statics.mt.cpp"
(dbx)
{noformat}
[Solaris Threads] SIGSEGV in 22.locale.statics.mt.cpp
-----------------------------------------------------
Key: STDCXX-811
URL:
https://issues.apache.org/jira/browse/STDCXX-811
Project: C++ Standard Library
Issue Type: Bug
Components: 22. Localization
Affects Versions: 4.2.0
Reporter: Martin Sebor
Assignee: Eric Lemings
Priority: Critical
Fix For: 4.2.1
Original Estimate: 4h
Time Spent: 1h
Remaining Estimate: 3h
Regardless of the compiler (gcc or Sun C++), when compiled
with Solaris Threads instead of POSIX threads, the
[22.locale.statics.mt|http://svn.apache.org/repos/asf/stdcxx/t
runk/tests/localization/22.locale.statics.mt.cpp] fails at
runtime with SIGSEGV or SIGHUP, suggesting a problem with the
uses of Solaris threads mutexes in the library.
I'm assuming this is not a regression but we need to check
the results of the test in 4.2.0 to make sure. If it is one,
it would make the priority of this issue a Blocker.
Otherwise, if it's not a new problem, we might be able to
defer it post 4.2.1 if it's too hard to fix.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
