Date: Fri, 31 Dec 2010 14:52:15 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: John Marino <freebsdml@marino.st> Cc: freebsd-threads@freebsd.org Subject: Re: AMD64 version of GNAT Ada compiler broken due to libthr Message-ID: <20101231125215.GL90883@deviant.kiev.zoral.com.ua> In-Reply-To: <4D1DCE02.3050601@marino.st> References: <4D1DC299.2090808@marino.st> <20101231122225.GK90883@deviant.kiev.zoral.com.ua> <4D1DCE02.3050601@marino.st>
next in thread | previous in thread | raw e-mail | index | archive | help
--OXqTiZo38oDXuAlq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 31, 2010 at 01:35:14PM +0100, John Marino wrote: > Hi Kostik, > You're right, that was an oversight. I'm using release 8.1, but I tried= =20 > troubleshooting this months ago on 8.0 and the result was identical. >=20 > I'm well above my head here. I don't know what I should be looking for.= =20 > Here's the dissembled _umtx_op_err function, along with the=20 > backtraces of the other two threads. They didn't look that interesting= =20 > to me the first time. The instruction counter is right before syscall, so I do think that the thread was executing the syscall. Backtrace for LWP 100073 indeed looks interesting, because the address 0x00007fffffbfeb19 belongs to the area used for stack(s), including the thread stacks. FreeBSD amd64 currently provides non-executable stacks for non-main threads, but executable stack for main thread. i386 has no support for nx bit on non-PAE kernels. As a useful experiment, go to src/lib/libthr/thread/thr_stack.c, find the following fragment if ((stackaddr =3D mmap(stackaddr, stacksize+guardsize, PROT_READ | PROT_WRITE, MAP_STACK, -1, 0)) !=3D MAP_FAILED && and change the flags from PROT_READ | PROT_WRITE to PROT_READ | PROT_WRITE | PROT_EXEC. Then recompile and reinstall libthr, and report back what happens with your test. >=20 > -- john >=20 >=20 >=20 > Starting program: /usr/home/marino/test_gnat/test_c9a009c/c9a009c > [New LWP 100086] > [New Thread 800a041c0 (LWP 100086)] > [New Thread 800a0ae40 (LWP 100051)] > [New Thread 800a64c80 (LWP 100073)] >=20 > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 800a64c80 (LWP 100073)] > 0x00007fffffbfeb19 in ?? () > Cannot set lwp 100073 registers: Invalid argument >=20 > An error occurred while in a function called from GDB. > Evaluation of the expression containing the function > (_umtx_op_err) will be abandoned. > When the function is done executing, GDB will silently stop. > Dump of assembler code for function _umtx_op_err: > 0x00000008006923c0 <+0>: mov $0x1c6,%rax > 0x00000008006923c7 <+7>: mov %rcx,%r10 > 0x00000008006923ca <+10>: syscall > 0x00000008006923cc <+12>: retq > 0x00000008006923cd <+13>: nop > 0x00000008006923ce <+14>: nop > 0x00000008006923cf <+15>: nop > 0x00000008006923d0 <+16>: mov 0x102d09(%rip),%rax #=20 > 0x8007950e0 > 0x00000008006923d7 <+23>: push %rbx > 0x00000008006923d8 <+24>: cmp $0xffffffffffffffff,%rax > 0x00000008006923dc <+28>: je 0x8006923f5 <_umtx_op_err+53> > 0x00000008006923de <+30>: lea 0x102cfb(%rip),%rbx #=20 > 0x8007950e0 > 0x00000008006923e5 <+37>: callq *%rax > 0x00000008006923e7 <+39>: mov -0x8(%rbx),%rax > 0x00000008006923eb <+43>: sub $0x8,%rbx > 0x00000008006923ef <+47>: cmp $0xffffffffffffffff,%rax > 0x00000008006923f3 <+51>: jne 0x8006923e5 <_umtx_op_err+37> > 0x00000008006923f5 <+53>: pop %rbx > 0x00000008006923f6 <+54>: retq > 0x00000008006923f7 <+55>: nop > End of assembler dump. > [Switching to thread 2 (Thread 800a041c0 (LWP 100086))]#0=20 > 0x00000008006923cc in _umtx_op_err () at=20 > /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 37 RSYSCALL_ERR(_umtx_op) > #0 0x00000008006923cc in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > #1 0x00000008006904c5 in cond_wait_common (cond=3D<value optimized out>, > mutex=3D0x800a0bb50, abstime=3D0x0, cancel=3D1) > at /usr/src/lib/libthr/thread/thr_cond.c:204 > #2 0x000000000040bfeb in=20 > system.tasking.stages.vulnerable_complete_master () > at s-tassta.adb:1696 > #3 0x000000000040620a in c9a009c () at c9a009c.adb:44 > [Switching to thread 4 (Thread 800a64c80 (LWP 100073))]#0=20 > 0x00007fffffbfeb19 in ?? () > #0 0x00007fffffbfeb19 in ?? () > #1 0x000000000040d655 in system.tasking.stages.task_wrapper ( > self_id=3D0x800a52500) at s-tassta.adb:1207 > #2 0x0000000800688621 in thread_start (curthread=3D0x800a64c80) > at /usr/src/lib/libthr/thread/thr_create.c:288 > #3 0x0000000000000000 in ?? () >=20 >=20 >=20 >=20 > Kostik Belousov wrote: > >On Fri, Dec 31, 2010 at 12:46:33PM +0100, John Marino wrote: > >>For several months I have been getting the GNAT Ada compiler to work=20 > >>properly on the four major BSDs. The i386 FreeBSD, the i386 Dragonfly= =20 > >>BSD, and the x86_64 Dragonfly BSD ports are currently perfect. The i38= 6=20 > >>and x86_64 ports of NetBSD are nearly perfect, and only lack a=20 > >>functional DWARF2 unwind mechanism, and the OpenBSD ports are in pretty= =20 > >>good shape too. The progress for this work can be seen at=20 > >>http://www.dragonlace.net > >> > >>However the AMD64 FreeBSD version is unusable and it's due to libthr. = =20 > >>I'm not sure why the i386 version works with libthr and AMD64 version= =20 > >>doesn't. For all four BSDs, there is no configuration difference for= =20 > >>threading between architectures. > >> > >>The problem seems to be with the pthread_cond_wait functionality. > >> > >>I've logged a test case segfault via gdb7.1 below. I would greatly=20 > >>appreciate some help in determining where the problem lies. If this=20 > >>problem can be solved, it will likely result in a perfect port of the= =20 > >>GNAT Ada compiler for FreeBSD AMD64, something that has not existed=20 > >>before. > >> > >First, you did not specified which version of the base system you use. > > > >Second, I suspect that the backtrace you have shown is not from the > >thread that generated SIGSEGV. Switch to other threads and see their > >backtraces, I am almost sure that there will be something more interesti= ng. > > > >Just to be sure, in gdb, disassemble _umtx_op_err() and see which > >instruction is executed when SIGSEGV generated. I think that the thread > >with the backtrace below is sleeping in syscall. > > > >>Regards, > >>John > >> --OXqTiZo38oDXuAlq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0d0f4ACgkQC3+MBN1Mb4hwqwCZAeMDG+MqPZzGjwHM0+8vKh88 6foAoPdcAgfqt+h46vo/EAF7zcjwMVlg =61kq -----END PGP SIGNATURE----- --OXqTiZo38oDXuAlq--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101231125215.GL90883>