This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
pthread6 vs hppa-linux
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: libstdc++ at gcc dot gnu dot org
- Date: Wed, 11 Dec 2002 19:13:57 -0500 (EST)
- Subject: pthread6 vs hppa-linux
I have been working on the pthread tests under hppa-linux and the atomic
locking implementation in glibc. The only atomic operation on the PA
requires 16 byte alignment and this is larger than the alignment normally
provided by malloc or gcc for stack locals. Anyway, I think that I
have a pthreads lock implementation that works but I am left with the
failure of pthread6.
I see this in the gdb backtrace:
#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)
at /home/dave/gcc-3.3/objdir/hppa-linux/libstdc++-v3/include/bits/char_traits.h:155
#3 0x00014bb8 in std::string::reserve(unsigned) (this=0x13ffec, __res=1913083)
at /home/dave/gcc-3.3/objdir/hppa-linux/libstdc++-v3/include/bits/basic_string.h:408
#4 0x00015024 in std::string::append(char const*, unsigned) (this=0x13ffec, __s=0xc7748 "Hallo Welt!", __n=11)
at /home/dave/gcc-3.3/objdir/hppa-linux/libstdc++-v3/include/bits/basic_string.tcc:595
#5 0x000102c4 in thread_main(void*) ()
at /home/dave/gcc-3.3/gcc/libstdc++-v3/testsuite/thread/pthread6.cc:59
#6 0x000604cc in pthread_start_thread (arg=0x40000000) at manager.c:291
#7 0x0008d5b0 in thread_start ()
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.
Any thoughts?
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)