Re: __rw::__string_ref::size sigsegv
On Thu, 20 Mar 2008 19:44:43 -0600 Martin Sebor <[EMAIL PROTECTED]> wrote: > 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. > >> > >> 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 Hello Martin, Great, thanks. I did an svn update to get the fix, rebuilt stdcxx, and confirmed this fixes the SEGV, thanks. > 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 Thanks. Just in case you wanted to report it to the Sun Compiler team, here is the link: http://forum.java.sun.com/ann.jspa?annID=30 Thanks, Mark --
Re: __rw::__string_ref::size sigsegv
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. 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 0xfd7fffdff3c9 which is 201 bytes above the current stack pointer [EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in std::pair::iterator>, bool>::operator= at 0x0040c7da 0x0040c7da: 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
Re: __rw::__string_ref::size sigsegv
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. 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. 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 0xfd7fffdff3c9 which is 201 bytes above the current stack pointer [EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in std::pair::iterator>, bool>::operator= at 0x0040c7da 0x0040c7da: 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
Re: __rw::__string_ref::size sigsegv
> 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 0xfd7fffdff3c9 > which is 201 bytes above the current stack pointer > [EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in > std::pair::iterator>, > bool>::operator= at 0x0040c7da > 0x0040c7da: 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 --
Re: __rw::__string_ref::size sigsegv
Mark Wright wrote:
Hello Martin and everyone,
Thanks. I added -D_RWSTDDEBUG to the Makefile like:
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? 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
PS FWIW, here's my dbx output with check -all:
Read from uninitialized (rui) on thread 1:
Attempting to read 7 bytes at address 0xfd7fffdff3c9
which is 201 bytes above the current stack pointer
[EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in std::pair::iterator>,
bool>::operator= at 0x0040c7da
0x0040c7da: 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
setstr : setstr.o
CC -D_RWSTDDEBUG -mt -g -xdebugformat=stabs -xs -m64 -library=%none
-I/h/goanna/1/a_5.10_m64/c/include -o setstr setstr.o
-L/h/goanna/1/a_5.10_m64/c/lib -R/h/goanna/1/a_5.10_m64/c/lib -lstd15D
setstr.o : setstr.cpp
CC -D_RWSTDDEBUG -mt -g -xdebugformat=stabs -xs -m64 -library=%none
-I/h/goanna/1/a_5.10_m64/c/include -c setstr.cpp
clean:
rm setstr setstr.o
compiled the following tiny program with Sun Studio 12 on Solaris 10u4 with
stdcxx
compiled from subversion as 64 bit 15D:
#include
#include
std::set setstr;
int main(int argc, char *argv[])
{
std::copy(argv, argv + argc, std::inserter(setstr, setstr.end()));
return 0;
}
and ran it, unfortunately though it still encounters a sigsegv. So
I tried running it in dbx with Run Time Checking:
goanna% dbx setstr
Reading setstr
Reading ld.so.1
Reading libstd15D.so.4.2.0
Reading libCrun.so.1
Reading libm.so.2
Reading libthread.so.1
Reading libc.so.1
dbx: warning: undefined type number (0,72) at
/h/goanna/2/eng/dev/stdcxx/setstr/setstr:setstr.cpp stab #64
nJ_C_link_t(0,69):t(0,71)=*(0,72),
assuming type `(int {assumed})'
(dbx) check -all
access checking - ON
memuse checking - ON
(dbx) run
Running: setstr
(process id 2876)
Reading rtcapihook.so
Reading libdl.so.1
Reading rtcaudit.so
Reading libmapmalloc.so.1
Reading libgen.so.1
Reading rtcboot.so
Reading librtc.so
RTC: Enabling Error Checking...
RTC: Running program...
Reading disasm.so
Read from uninitialized (rui) on thread 1:
Attempting to read 8 bytes at address 0x424818
which is 32 bytes into a heap block of size 1280 bytes at 0x4247f8
This block was allocated from:
[1] operator new() at 0xfd7fddb0a0e9
[2] __rw::__rw_allocate() at line 61 in "memory.cpp"
[3] std::allocator<__rw::__rw_rb_tree_node,std::allocator >
>,std::basic_string,std::allocator >,std::basic_string,std::allocator
>,__rw::__ident,std::allocator >,std::basic_string,std::allocator > >
> >::allocate() at line 144 in "_allocator.h"
[4] __rw::__rb_tree,std::allocator >,std::basic_string,std::allocator
>,__rw::__ident,std::allocator >,std::basic_string,std::allocator >
>,std::less,std::allocator > >,std::allocator,std::allocator > >
>::_C_add_new_buffer() at line 143 in "_tree.cc"
[5] __rw::__rb_tree,std::allocator >,std::basic_string,std::allocator
>,__rw::__ident,std::allocator >,std::basic_string,std::allocator >
>,std::less,std::allocator > >,std::allocator,std::allocator > >
>::_C_get_link() at line 360 in "_tree.h"
[6] __rw::__rb_tree,std::allocator >,std::basic_string,std::allocator
>,__rw::__ident,std::allocator >,std::basic_string,std::allocator >
>,std::less,std::allocator > >,std::allocator,std::allocator > >
>::_C_get_node() at line 393 in "_tree.h"
[7] __rw::__rb_tree,std::allocator >,std::basic_string,std::allocator
>,__rw::__ident,std::allocator >,std::basic_string,std::allocator >
>,std::less,std::allocator > >,std::allocator,std::allocator > >
>::_C_init() at line 460 in "_tree.h"
[8] __rw::__rb_tree,std::allocator >,std::basic_string,std::allocator
>,__rw::__ident,std::allocator >,std::basic_string,std::allocator >
>,std::less,std::allocator > >,std::allocator,std::allocator > >
>::__rb_tree() at line 56 in "_tree.cc"
Variable is 'this'
[EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in
std::basic_string,std::allocator >::_C_pref at line 842
in file "string"
842 return _RWSTD_REINTERPRET_CAST (_C_string_ref_type*, _C_data) - 1;
(dbx) where
current thread: [EMAIL PROTECTED]
=>[1]
Re: __rw::__string_ref::size sigsegv
Hello Martin and everyone,
Thanks. I added -D_RWSTDDEBUG to the Makefile like:
setstr : setstr.o
CC -D_RWSTDDEBUG -mt -g -xdebugformat=stabs -xs -m64 -library=%none
-I/h/goanna/1/a_5.10_m64/c/include -o setstr setstr.o
-L/h/goanna/1/a_5.10_m64/c/lib -R/h/goanna/1/a_5.10_m64/c/lib -lstd15D
setstr.o : setstr.cpp
CC -D_RWSTDDEBUG -mt -g -xdebugformat=stabs -xs -m64 -library=%none
-I/h/goanna/1/a_5.10_m64/c/include -c setstr.cpp
clean:
rm setstr setstr.o
compiled the following tiny program with Sun Studio 12 on Solaris 10u4 with
stdcxx
compiled from subversion as 64 bit 15D:
#include
#include
std::set setstr;
int main(int argc, char *argv[])
{
std::copy(argv, argv + argc, std::inserter(setstr, setstr.end()));
return 0;
}
and ran it, unfortunately though it still encounters a sigsegv. So
I tried running it in dbx with Run Time Checking:
goanna% dbx setstr
Reading setstr
Reading ld.so.1
Reading libstd15D.so.4.2.0
Reading libCrun.so.1
Reading libm.so.2
Reading libthread.so.1
Reading libc.so.1
dbx: warning: undefined type number (0,72) at
/h/goanna/2/eng/dev/stdcxx/setstr/setstr:setstr.cpp stab #64
nJ_C_link_t(0,69):t(0,71)=*(0,72),
assuming type `(int {assumed})'
(dbx) check -all
access checking - ON
memuse checking - ON
(dbx) run
Running: setstr
(process id 2876)
Reading rtcapihook.so
Reading libdl.so.1
Reading rtcaudit.so
Reading libmapmalloc.so.1
Reading libgen.so.1
Reading rtcboot.so
Reading librtc.so
RTC: Enabling Error Checking...
RTC: Running program...
Reading disasm.so
Read from uninitialized (rui) on thread 1:
Attempting to read 8 bytes at address 0x424818
which is 32 bytes into a heap block of size 1280 bytes at 0x4247f8
This block was allocated from:
[1] operator new() at 0xfd7fddb0a0e9
[2] __rw::__rw_allocate() at line 61 in "memory.cpp"
[3]
std::allocator<__rw::__rw_rb_tree_node,std::allocator
> >,std::basic_string,std::allocator
>,std::basic_string,std::allocator
>,__rw::__ident,std::allocator
>,std::basic_string,std::allocator > > >
>::allocate() at line 144 in "_allocator.h"
[4]
__rw::__rb_tree,std::allocator
>,std::basic_string,std::allocator
>,__rw::__ident,std::allocator
>,std::basic_string,std::allocator >
>,std::less,std::allocator
>
>,std::allocator,std::allocator
> > >::_C_add_new_buffer() at line 143 in "_tree.cc"
[5]
__rw::__rb_tree,std::allocator
>,std::basic_string,std::allocator
>,__rw::__ident,std::allocator
>,std::basic_string,std::allocator >
>,std::less,std::allocator
>
>,std::allocator,std::allocator
> > >::_C_get_link() at line 360 in "_tree.h"
[6]
__rw::__rb_tree,std::allocator
>,std::basic_string,std::allocator
>,__rw::__ident,std::allocator
>,std::basic_string,std::allocator >
>,std::less,std::allocator
>
>,std::allocator,std::allocator
> > >::_C_get_node() at line 393 in "_tree.h"
[7]
__rw::__rb_tree,std::allocator
>,std::basic_string,std::allocator
>,__rw::__ident,std::allocator
>,std::basic_string,std::allocator >
>,std::less,std::allocator
>
>,std::allocator,std::allocator
> > >::_C_init() at line 460 in "_tree.h"
[8]
__rw::__rb_tree,std::allocator
>,std::basic_string,std::allocator
>,__rw::__ident,std::allocator
>,std::basic_string,std::allocator >
>,std::less,std::allocator
>
>,std::allocator,std::allocator
> > >::__rb_tree() at line 56 in "_tree.cc"
Variable is 'this'
[EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in
std::basic_string,std::allocator >::_C_pref
at line 842 in file "string"
842 return _RWSTD_REINTERPRET_CAST (_C_string_ref_type*, _C_data) -
1;
(dbx) where
current thread: [EMAIL PROTECTED]
=>[1] std::basic_string,std::allocator
>::_C_pref(this = 0x424818), line 842 in "string"
[2] std::basic_string,std::allocator
>::size(this = 0x424818), line 247 in "string"
[3] std::basic_string,std::allocator
>::size(this = 0x424818), line 247 in "string"
[4] std::basic_string,std::allocator
>::compare(this = 0x424818, __str = CLASS), line 1186 in "string"
[5] std::operator< ,std::allocator >(__lhs
= CLASS, __rhs = CLASS), line 1356 in "string"
[6]
std::less,std::allocator >
>::operator()(this = 0x422778, __x = CLASS, __y = CLASS), line 94 in
"_funcbase.h"
[7]
__rw::__rb_tree,std::allocator
>,std::basic_string,std::allocator
>,__rw::__ident,std::allocator
>,std::basic_string,std::allocator >
>,std::less,std::allocator
>
>,std::allocator,std::allocator
> > >::insert(this = 0x422748, __it = CLASS, __v = CLASS, __dup = false), line
356 in "_tree.cc"
[8]
__rw::__rb_tree,std::allocator
>,std::basic_string,std::allocator
>,__rw::__ident,std::allocator
>,std::basic_string,std::allocator >
>,std::less,std::allocator
>
>,std::allocator,std::allocator
> > >::insert(this = 0x422748, __it = CLASS, __x = CLASS, __dup = false), line
592 in "_tree.h"
[9]
std::set,std::allocator
>,std::less,std::allocator
>
>,std::allocator,std::allocator
> >
Re: __rw::__string_ref::size sigsegv
Mark Wright wrote:
Hi,
I compile the following program with Sun Studio 12 on Solaris 10u4
with stdcxx compiled from subversion as 64 bit 15D:
The program needs to be the same configuration (build type)
as the library. Since your library is 15D (debug, shared,
wide), your program needs to be compiled the same way (i.e.,
debug and wide). Your command line seems to be missing
_RWSTDDEBUG (the library is binary incompatible between
debug and optimized builds).
You can see the set of command line options we use when
compiling and linking the library and the tests in our
nightly builds here: http://tinyurl.com/27oaaq
Martin
#include
#include
std::set setstr;
int main(int argc, char *argv[])
{
std::copy(argv, argv + argc, std::inserter(setstr, setstr.end()));
return 0;
}
With a Makefile like:
setstr : setstr.o
CC -D_REENTRANT -mt -g -xdebugformat=stabs -xs -xtarget=opteron -m64
-library=no%Cstd -library=Crun -I/h/goanna/1/a_5.10_m64/c/include -o setstr
setstr.o -L/h/goanna/1/a_5.10_m64/c/lib -R/h/goanna/1/a_5.10_m64/c/lib -lstd15D
setstr.o : setstr.cpp
CC -D_REENTRANT -mt -g -xdebugformat=stabs -xs -xtarget=opteron -m64
-library=no%Cstd -library=Crun -I/h/goanna/1/a_5.10_m64/c/include -c setstr.cpp
clean:
rm setstr setstr.o
and run it (with no command line arguments), and it crashes with the stack
trace below. I was wondering if I am doing something wrong (it works fine
when compiled instead with -library=stlport4), or if you can reproduce it?
Thanks, Mark
goanna% gmake
CC -D_REENTRANT -mt -g -xdebugformat=stabs -xs -xtarget=opteron -m64
-library=no%Cstd -library=Crun -I/h/goanna/1/a_5.10_m64/c/include -c setstr.cpp
CC -D_REENTRANT -mt -g -xdebugformat=stabs -xs -xtarget=opteron -m64
-library=no%Cstd -library=Crun -I/h/goanna/1/a_5.10_m64/c/include -o setstr
setstr.o -L/h/goanna/1/a_5.10_m64/c/lib -R/h/goanna/1/a_5.10_m64/c/lib -lstd15D
goanna% ./setstr
zsh: segmentation fault (core dumped) ./setstr
goanna% dbx ./setstr core
Reading setstr
core file header read successfully
Reading ld.so.1
Reading libstd15D.so.4.2.0
Reading libCrun.so.1
Reading libm.so.2
Reading libthread.so.1
Reading libc.so.1
[EMAIL PROTECTED] ([EMAIL PROTECTED]) program terminated by signal SEGV (no
mapping at the fault address)
dbx: warning: undefined type number (0,71) at
/h/goanna/2/eng/dev/stdcxx/setstr/./setstr:setstr.cpp stab #63
nJ_C_link_t(0,68):t(0,70)=*(0,71),
assuming type `(int {assumed})'
Current function is
__rw::__string_ref,std::allocator >::size
211 return _C_size._C_size;
(dbx) where
current thread: [EMAIL PROTECTED]
=>[1] __rw::__string_ref,std::allocator >::size(this =
0xffe8), line 211 in "_strref.h"
[2] std::basic_string,std::allocator >::size(this =
0x41e8f0), line 247 in "string"
[3] std::basic_string,std::allocator >::compare(this
= 0x41e8f0, __str = CLASS), line 1186 in "string"
[4] std::operator< ,std::allocator >(__lhs = CLASS,
__rhs = CLASS), line 1356 in "string"
[5] std::less,std::allocator >
>::operator()(this = 0x41d060, __x = CLASS, __y = CLASS), line 94 in "_funcbase.h"
[6] __rw::__rb_tree,std::allocator >,std::basic_string,std::allocator
>,__rw::__ident,std::allocator >,std::basic_string,std::allocator >
>,std::less,std::allocator > >,std::allocator,std::allocator > >
>::insert(this = 0x41d030, __it = CLASS, __v = CLASS, __dup = false), line 356 in "_tree.cc"
[7] __rw::__rb_tree,std::allocator >,std::basic_string,std::allocator
>,__rw::__ident,std::allocator >,std::basic_string,std::allocator >
>,std::less,std::allocator > >,std::allocator,std::allocator > >
>::insert(this = 0x41d030, __it = CLASS, __x = CLASS, __dup = false), line 592 in "_tree.h"
[8] std::set,std::allocator
>,std::less,std::allocator >
>,std::allocator,std::allocator > > >::insert(this = 0x41d030, __it = CLASS,
__x = CLASS), line 172 in "set"
[9] std::insert_iterator,std::allocator
>,std::less,std::allocator >
>,std::allocator,std::allocator > > > >::operator=(this = 0xfd7fffdfd6d0, __x
= CLASS), line 501 in "_iterator.h"
[10] std::copy,std::allocator
>,std::less,std::allocator >
>,std::allocator,std::allocator > > > > >(__first = 0xfd7fffdfd798, __last =
0xfd7fffdfd7a0, __res = CLASS), line 95 in "_algobase.h"
[11] main(argc = 1, argv = 0xfd7fffdfd798), line 8 in "setstr.cpp"
(dbx) print -r *this
dbx: cannot access address 0xffe8
(dbx) frame 2
Current function is
std::basic_string,std::allocator >::size
247 return _C_pref ()->size ();
(dbx) print -r *this
*this = {
basic_string,std::allocator >::_C_data
= (nil)
basic_string,std::allocator >::npos
= -1
_C_null_ref = struct
__rw::__null_ref,std::allocator > /* STATIC
CLASS */
}
(dbx) loadobject -list
m /h/goanna/2/eng/dev/stdcxx/setstr/./setstr (primary)
m /h/goanna/1/a_5.10_m64/c/lib/libstd15D.so.4.2.0
m
