stdcxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: __rw::__string_ref::size sigsegv
Date Fri, 21 Mar 2008 01:44:43 GMT
Martin Sebor wrote:
> Mark Wright wrote:
>>> 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.
> 
> 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:
   http://svn.apache.org/viewvc?view=rev&revision=639495

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:
http://issues.apache.org/jira/browse/STDCXX-87?focusedCommentId=12580978#action_12580978

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

Martin

> 
>>
>>> 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:
> 
> Okay, those should be fine.
> 
>>
>> 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?
> 
> Correct. Or with trunk with the patch below reverted:
>   http://svn.apache.org/viewcvs?view=rev&rev=616673
> 
> Martin
> 


Mime
View raw message