Martin Sebor wrote:
Mark Wright wrote:
On Thu, 20 Mar 2008 09:26:19 -0600
Martin Sebor <[EMAIL PROTECTED]> wrote:
I couldn't reproduce the SEGV with 4.2.0 but I did reproduce it on
the head of trunk (both with Sun C++/Solaris and gcc/Linux). I could
reproduce the RUI in set::insert(). It turns out the RUI is a known
issue (http://issues.apache.org/jira/browse/STDCXX-87) that hasn't
been analyzed yet. I'm not sure it's related to the SEGV. Let me
spend some time on it today and get back to you.
Just to confirm: you're still using 4.2.0, correct?
No, I built it from subversion yesterday.
Okay, that explains the SEGV. We've recently introduced a regression
on trunk that's causing the problem. We should have a fix for it soon.
Travis checked in a fix for the SEGV:
I've also made some progress on the RUI in set::insert(). My take
on it is that it's probably a compiler bug. See the details here:
I don't have a small test case to send to Sun and I'm not 100% sure
it's benign so I'll see if there's a way to work around it other
than by defining the copy assignment operator in std::pair (it
may not be the most efficient solution). Check the issue for
And you used
the stock command line options to build the library without any
changes of your own (i.e., whatever our makefile uses)?
I built it with these minor tweaks:
Okay, those should be fine.
--- stdcxx/etc/config/sunpro.config (revision 639143)
+++ stdcxx/etc/config/sunpro.config (working copy)
@@ -74,7 +74,7 @@
RPATH = -R
# debug/optimization options
-DEBUG_CXXFLAGS = -g
+DEBUG_CXXFLAGS = -g -xdebugformat=stabs
OPTMZ_CXXFLAGS = -O
@@ -126,8 +126,8 @@
# starting with Sun C++ 5.9, the compiler prefers the generic
# -m32 and -m64 options to the architecture specific -xarch
# options some of which have been deprecated
- wide_flags = -m64
- narrow_flags = -m32
+ wide_flags = -xtarget=opteron -m64
+ narrow_flags = -xtarget=opteron -m32
# (try to) determine the architecture via the (non-standard)
# -p option recognized on (at least) Linux and Solaris
with the stock 15D command line options:
gmake BUILDDIR=/h/goanna/2/ta/stdcxx/stdcxx/build/15D BUILDTYPE=15D
PS FWIW, here's my dbx output with check -all:
Read from uninitialized (rui) on thread 1:
Attempting to read 7 bytes at address 0xfffffd7fffdff3c9
which is 201 bytes above the current stack pointer
[EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in std::pair<std::set<std::string>::iterator>,
bool>::operator= at 0x000000000040c7da
0x000000000040c7da: operator=+0x002a: hlt
Checking for memory leaks...
Actual leaks report (actual leaks: 0 total size: 0
Possible leaks report (possible leaks: 0 total size: 0
Checking for memory use...
Blocks in use report (blocks in use: 0 total size: 0
execution completed, exit code is 0
I guess since there was no sigsegv with this dbx check -all
run, that this was with 4.2.0?
Correct. Or with trunk with the patch below reverted: