From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1641 invoked by alias); 17 Jun 2014 17:31:37 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 1592 invoked by uid 48); 17 Jun 2014 17:31:31 -0000 From: "kumba at gentoo dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/61538] New: g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux Date: Tue, 17 Jun 2014 17:31:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc cf_gcchost cf_gcctarget cf_gccbuild Message-ID: 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/msg01498.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 Bug ID: 61538 Summary: g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kumba at gentoo dot org CC: toolchain at gentoo dot org Host: mips-unknown-linux-gnu Target: mips-unknown-linux-gnu Build: mips-unknown-linux-gnu I appear to have run into a regression in g++/libstdc++, starting with at least 4.8.2, where a simple binary built by g++ and linked to glibc-2.19's libpthread causes the binary to hang on a kernel futex() syscall (syscall #4328 in o32 ABI) until killed or interrupted w/ ctrl-C. I have replicated this problem in an o32 environment, as well as an n32 and n64 multilib environment. So far, the identified trigger conditions are: - Must be an R10000-based SGI system (SGI O2 w/ RM7000 does not reproduce) - Must compile testcase w/ 'g++' (compiling with 'gcc' works fine) - Must link w/ -lpthread from at least glibc-2.19 (doesn't seem to trigger on older versions). - Must be gcc-4.8.2 or greater (gcc-4.6.4 and gcc-4.7.3 both work fine). I ran into this while getting Linux support for the SGI Octane operational again and rebuilding a ~5-year old Gentoo userland on the machine. I at first thought it was a problem with old libs still living on the system that I haven't purged just yet, but I have been able to recreate the problem in a clean n32/n64 Gentoo stage3 chroot. The Octane in particular has an R14000 CPU module installed right now, though I can also trigger the condition on an R12000 CPU module as well. I don't have any other working R1x000-capable SGI hardware available at the moment to test this on, so this could still be a quirky bug in the Octane's kernel, but I believe this is less likely since I can trigger the problem only with specific versions of libstdc++. Sample C code that I can use to trigger the issue with from Python-3.3.5's configure script (where it etsts for thread support): # cat conftest.c void foo();int main(){foo();}void foo(){} Compiler command line: # g++ -o conftest conftest.c -lpthread # ./conftest Overriding LD_PRELOAD to use libstdc++ from an earlier gcc: # LD_PRELOAD=/usr/lib/gcc/mips-unknown-linux-gnu/4.9.0/libstdc++.so.6 ./conftest # LD_PRELOAD=/usr/lib/gcc/mips-unknown-linux-gnu/4.8.2/libstdc++.so.6 ./conftest # LD_PRELOAD=/usr/lib/gcc/mips-unknown-linux-gnu/4.7.3/libstdc++.so.6 ./conftest I don't have much more than that at the moment, but let me know if there are specific command outputs needed to further determine what the cause of this problem is.