[Solaris Threads] SIGSEGV in 22.locale.statics.mt.cpp

• Key: STDCXX-811
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Critical
• Assignee: Eric Lemings
• Reporter: Martin Sebor
• Component/s: 22. Localization
• Affects Version/s: 4.2.0
• Fix Version/s: 4.2.1

Description

Regardless of the compiler (gcc or Sun C++), when compiled with Solaris Threads instead of POSIX threads, the 22.locale.statics.mt 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.

Comments

[Eric Lemings]

This test ran fine on the following Solaris platform:

SunOS host 5.10 Generic_118833-33 sun4u sparc SUNW,Sun-Fire-V215
CC: Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25
BUILDMODE=debug,pthreads,shared CONFIG=sunpro.config

What particular configuration was this failure observed with?

[Eric Lemings]

Woops. Wrong thread model. Nvm.

[Eric Lemings]

Weird. The test fails as described when executed using the `runall' target in the Makefile but runs fine from the command line. Must be some difference between my test environment and the environment invoked from the Makefile.

[Martin Sebor]

Don't forget the exec utility invokes tests with a bunch of arguments and I/O redirects.

[Eric Lemings]

Since the failure occurs in 64-bit builds and I have LD_LIBRARY_PATH_64 set in my environment but the Makefile does not invoke the test program with this environment variable, I highly suspect the failure is due to not setting the LD_LIBRARY_PATH_64 environment variable.

I temporarily modified the makefile.rules to test this theory. The test is still running: either its a long test ("with 2 threads, 20000 iterations each, in 16 locales" could take a while) or its stuck in an indefinite loop.

[Eric Lemings]

Where do I find the arguments used to invoke the exec utility? I don't see them anywhere in the log files for the test results.

[Martin Sebor]

See the RUNFLAGS make variable in GNUmakefile.tst and the run target in makefile.rules.

[Eric Lemings]

Here's a stack trace where the test is failing, just for the record.

[user@host 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 [e-mail].3
t@5 (l@5) 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: t@5
  [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)

[Eric Lemings]

http://svn.apache.org/viewvc?view=rev&revision=644466

[Eric Lemings]

Can't use __rw_setlocale object because of destructor.

[Martin Sebor]

Not merged out to 4.2.x yet – reopening.

[Martin Sebor]

Resolving as fixed.
Will close after integrating to 4.2.x in the next bulk merge.

[Farid Zaripov]

Merged in 4.2.x branch thus: http://svn.apache.org/viewvc?view=rev&revision=648752