Date: Fri, 31 Dec 2010 14:22:25 +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: <20101231122225.GK90883@deviant.kiev.zoral.com.ua> In-Reply-To: <4D1DC299.2090808@marino.st> References: <4D1DC299.2090808@marino.st>
next in thread | previous in thread | raw e-mail | index | archive | help
--5nbaS3kz4OSBzmjj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 i386= =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 >=20 > 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. >=20 > The problem seems to be with the pthread_cond_wait functionality. >=20 > 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 befor= e. >=20 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 interesting. 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 >=20 >=20 >=20 > Starting program: /usr/home/marino/test_gnat/test_c9a009c/c9a009c > [New LWP 100051] > [New Thread 800a041c0 (LWP 100051)] > [New Thread 800a0ae40 (LWP 100073)] > [New Thread 800a64c80 (LWP 100080)] >=20 > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 800a64c80 (LWP 100080)] > 0x00007fffffbfeb19 in ?? () > * 4 Thread 800a64c80 (LWP 100080) 0x00007fffffbfeb19 in ?? () > 3 Thread 800a0ae40 (LWP 100073) 0x00000008006923cc in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 2 Thread 800a041c0 (LWP 100051) 0x00000008006923cc in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > [Switching to thread 3 (Thread 800a0ae40 (LWP 100073))]#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=3D0x800a0c850, abstime=3D0x0, cancel=3D1) > at /usr/src/lib/libthr/thread/thr_cond.c:204 > #2 0x000000000040ca0f in system.tasking.stages.activate_tasks ( > chain_access=3D0x7fffffbfebb0) at s-tassta.adb:382 > #3 0x0000000000405950 in c9a009c.t1 (<_task>=3D<value optimized out>) > at c9a009c.adb:52 > #4 0x000000000040d655 in system.tasking.stages.task_wrapper ( > self_id=3D0x800a0c700) at s-tassta.adb:1207 > #5 0x0000000800688621 in thread_start (curthread=3D0x800a0ae40) > at /usr/src/lib/libthr/thread/thr_create.c:288 > #6 0x0000000000000000 in ?? () >=20 > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" --5nbaS3kz4OSBzmjj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0dywEACgkQC3+MBN1Mb4jgiACgzoYleA1zTSTDb+eI9lMBUIvh unMAoMLsA3f0gEJj96lql/hRexoajSCm =Fx6b -----END PGP SIGNATURE----- --5nbaS3kz4OSBzmjj--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101231122225.GK90883>