> 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.
Hello Martin,
Great, thanks.
> Just to confirm: you're still using 4.2.0, correct?
No, I built it from subversion yesterday.
> And you used
> the stock command line options to build the library without any
> changes of your own (i.e., whatever our makefile uses)?
>
> Martin
I built it with these minor tweaks:
Index: stdcxx/etc/config/sunpro.config
===================================================================
--- 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
DEBUG_CPPFLAGS =
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
else
# (try to) determine the architecture via the (non-standard)
# -p option recognized on (at least) Linux and Solaris
goanna%
with the stock 15D command line options:
gmake BUILDDIR=/h/goanna/2/ta/stdcxx/stdcxx/build/15D BUILDTYPE=15D
CONFIG=sunpro.config
> 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
> (dbx) cont
> Checking for memory leaks...
>
> Actual leaks report (actual leaks: 0 total size:
> 0 bytes
> )
>
>
>
> Possible leaks report (possible leaks: 0 total size:
> 0 bytes
> )
>
>
> Checking for memory use...
>
> Blocks in use report (blocks in use: 0 total size:
> 0 bytes
> )
>
>
>
> 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?
Thanks, Mark
--
