Re: ld.elf_so i386 memcpy corruption - calligrawords hangs

2013-10-17 Thread Nat Sloss
Hi, I have some concerns about the tls variant 2 implementation. As it stands thread local storage will over write the tcb is this intentional or should it be like this: Index: src/libexec/ld.elf_so/tls.c === RCS file: /cvsroot/src

daily CVS update output

2013-10-17 Thread NetBSD source update
Updating src tree: P src/distrib/sets/lists/comp/mi P src/external/bsd/libc++/include/Makefile P src/external/mit/xorg/lib/libX11/Makefile.libx11 P src/external/mit/xorg/lib/libXi/Makefile P src/lib/libc/arch/sparc/gen/fpsetsticky.c P src/lib/libc/gen/arc4random.c P src/lib/libc/rpc/clnt_vc.c P sr

amd64 build break - liblfs/ulfs_quota2.c

2013-10-17 Thread Paul Goyette
Looks like someone was a bit overly energetic with clean-up? :) With sources current at 00:54 UTC: # compile liblfs/ulfs_quota2.o /test-bed/tools/bin/x86_64--netbsd-gcc -O2 -DLFS_KERNEL_RFW -ffreestanding -fno-strict-aliasing -mno-red-zone -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-p

Re: ld.elf_so i386 memcpy corruption - calligrawords hangs

2013-10-17 Thread Nat Sloss
Hi, Thanks to all that posted. I ended up solving the issue. I was able to retrieve the obj->path which was /usr/pkg/bin/libmpfr.so.4 which I didn't think was a dependency (ldd /usr/pkg/bin/calligrawords did not mention liibmpfr). So I looked at the math/mpfr package, there was a configure

Automated report: NetBSD-current/i386 build failure

2013-10-17 Thread NetBSD Test Fixture
This is an automatically generated notice of a NetBSD-current/i386 build failure. The failure occurred on babylon5.NetBSD.org, a NetBSD/amd64 host, using sources from CVS date 2013.10.17.20.57.58. An extract from the build.sh output follows: --- dependall-arch --- --- notdi2.d --- #

Re: ld.elf_so i386 memcpy corruption - calligrawords hangs

2013-10-17 Thread David Laight
On Thu, Oct 17, 2013 at 10:45:08AM +0200, Martin Husemann wrote: > You could uncomment the following lines in the src/libexec/ld.elf_so/Makefile > > #CPPFLAGS+= -DDEBUG > #CPPFLAGS+= -DRTLD_DEBUG > > (re-)build and install ld.elf_so, and set LD_DEBUG=1 when starting the > program. > Be

Re: ld.elf_so i386 memcpy corruption - calligrawords hangs

2013-10-17 Thread Martin Husemann
You could uncomment the following lines in the src/libexec/ld.elf_so/Makefile #CPPFLAGS+= -DDEBUG #CPPFLAGS+= -DRTLD_DEBUG (re-)build and install ld.elf_so, and set LD_DEBUG=1 when starting the program. But better keep a copy of old ld.elf_so around and a root shell open so you can resto

Re: ld.elf_so i386 memcpy corruption - calligrawords hangs

2013-10-17 Thread Nat Sloss
Hi, I've since found that _rtld_objlist starts with an invalid pointer. so by setting obj = obj+4 which is a valid pointer the program runs. It creates three threads so I have to repeat the process above and interestingly obj from _rtld_objlist starts with the same invalid pointer each time. S

ld.elf_so i386 memcpy corruption - calligrawords hangs

2013-10-17 Thread Nat Sloss
Hi, I have made a package of calligra 2.7.2 and I am trying to get calligrawords and calligra author to work. I have built all libraries with symbols and upon analysis with gdb I have found the following: NB: This was obtained on a machine running NetBSD 6.1.1 i386 PAE kernel, but I believe t