This is the mail archive of the
mailing list for the libstdc++ project.
Re: pthread6 vs hppa-linux
- From: Phil Edwards <phil at jaj dot com>
- To: John David Anglin <dave at hiauly1 dot hia dot nrc dot ca>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Thu, 12 Dec 2002 21:04:48 -0500
- Subject: Re: pthread6 vs hppa-linux
- References: <200212120013.gBC0DvwN021576@hiauly1.hia.nrc.ca>
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