stdcxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Wright <markwri...@internode.on.net>
Subject Re: __rw::__string_ref::size sigsegv
Date Thu, 20 Mar 2008 22:27:07 GMT
> On Thu, 20 Mar 2008 09:26:19 -0600
> Martin Sebor <sebor@roguewave.com> 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
> t@1 (l@1) 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

-- 

Mime
View raw message