This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pthread6 vs hppa-linux


On Wed, Dec 11, 2002 at 07:13:57PM -0500, John David Anglin wrote:
> 
> #0  _wordcopy_fwd_aligned (dstp=1141769664, srcp=2097144, len=248528)
>     at ../sysdeps/generic/wordcopy.c:103
> #1  0x00082d30 in memcpy (dstpp=0x44000014, srcpp=0x1ffff8, len=1913072)
>     at ../sysdeps/generic/memcpy.c:55
> #2  0x00016e8c in std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned) (this=0x11fa3c, __alloc=@0x1ffff8, __res=248528)

[...]

> The code in _wordcopy_fwd_aligned causes a segementation fault:
> 
> Dec 11 14:27:54 gsyprf11 kernel: do_page_fault() pid=21129 command='pthread6.xgs' type=15 address=0x00200000
> Dec 11 14:27:54 gsyprf11 kernel: vm_start = 0x00120000, vm_end = 0x00200000
> 
> The memcpy accesses memory beyond that allocated.  I have the sense that
> _M_clone is supposed to catch copy failures but I am not quite sure.  If
> it is, this might indicate a problem with the hppa-linux v3 implementation of
> the trap handler.

_M_clone catches copy failures in the literal C++ sense of catches:  if
the copy operations throws an exception, it does some cleanup, and then
propogates the exception (as required).  It does nothing to ward against
bad implementations of memcpy, or any other kind of segmentation fault.

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]