From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-454629-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 10624 invoked by alias); 21 Jun 2014 01:21:48 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 10559 invoked by uid 48); 21 Jun 2014 01:21:40 -0000
From: "kumba at gentoo dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux
Date: Sat, 21 Jun 2014 01:21:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: kumba at gentoo dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61538-4-RhooxlX1dc@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61538-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61538-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-06/txt/msg01711.txt.bz2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538

--- Comment #10 from Joshua Kinard <kumba at gentoo dot org> ---
I rebuilt both glibc-2.19 and gcc-4.8.3 w/ debugging, though gcc's build system
managed to strip out or optimize away some of the debugging code.  That said,
it's enough to see that the hang is being triggered by gcc because it makes two
futex syscalls in gcc-4.8.3/libstdc++-v3/libsupc++/guard.cc:290:
    syscall (SYS_futex, gi, _GLIBCXX_FUTEX_WAIT, expected, 0);

The first one lines up with the strace output where it gets -1 EAGAIN, and then
the second attempt is where the program hangs.

>>From GDB:
(gdb) r
Starting program: /usr/obj/mips-unknown-linux-gnu/c2
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".

Catchpoint 1 (call to syscall 4238), __pthread_initialize_minimal_internal ()
at nptl-init.c:328
(gdb) c
Continuing.

Catchpoint 1 (call to syscall 4238), 0x77f9dd90 in
__pthread_initialize_minimal_internal () at nptl-init.c:348
(gdb) break *0x77d2b684
Breakpoint 2 at 0x77d2b684: file ../sysdeps/unix/syscall.S, line 27.
(gdb) break *0x77ec621c
Breakpoint 3 at 0x77ec621c: file
/usr/obj/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/libstdc++-v3/libsupc++/guard.cc,
line 290.
(gdb) c
Continuing.

Breakpoint 3, 0x77ec621c in __cxxabiv1::__cxa_guard_acquire (g=0x77f95500
<guard variable for (anonymous
namespace)::__future_category_instance()::__fec>)
    at
/usr/obj/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/libstdc++-v3/libsupc++/guard.cc:290
(gdb) c
Continuing.

Breakpoint 2, 0x77d2b684 in syscall () at ../sysdeps/unix/syscall.S:27
(gdb) c
Continuing.

Breakpoint 3, 0x77ec621c in __cxxabiv1::__cxa_guard_acquire (g=0x77f95500
<guard variable for (anonymous
namespace)::__future_category_instance()::__fec>)
    at
/usr/obj/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/libstdc++-v3/libsupc++/guard.cc:290
(gdb) c
Continuing.
<HANGS HERE>
^C
Program received signal SIGINT, Interrupt.
0x77d2b684 in syscall () at ../sysdeps/unix/syscall.S:27
(gdb)