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.
>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.
>
>
