From owner-freebsd-bugs@FreeBSD.ORG Thu Apr 23 08:29:55 2015 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6546D46 for ; Thu, 23 Apr 2015 08:29:55 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 973341C07 for ; Thu, 23 Apr 2015 08:29:55 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3N8TtEb058548 for ; Thu, 23 Apr 2015 08:29:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 199557] Hang on sysconf(_SC_OPEN_MAX) Date: Thu, 23 Apr 2015 08:29:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ikosarev@accesssoftek.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 08:29:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199557 --- Comment #5 from ikosarev@accesssoftek.com --- (In reply to Ed Maste from comment #2) > Pointed out by kib, when invoking the fork syscall directly the child > inherits potentially locked libc mutexes, and it's probably the printf > that hangs, not the sysconf. Note that the code doesn't leverage libc's printf(), but rather uses its own version of it. > What was the original underlying issue here? The original problem is random Tsan tests hanging on high loaded machines like the FreeBSD sanitizers buildbot: http://lab.llvm.org:8011/builders/sanitizer_x86_64-freebsd/builds/4978/steps/make-check-tsan/logs/stdio It mostly work fine when the tests run in about 4 threads, but tends to fail constantly when run in about 64 threads--doesn't matter how much cores the hardware has. This is how it leads to the point of hang: during execution of a Tsan tests the Tsan STL catches a data race or other condition triggering a run-time report. That report contains references to related object files and associated addresses. These file names together with the addresses are then translated into source file name, line numbers and function names by calling the llvm-symbolizer or, if the RTL is unable to locate it, the addr2line command. To catch the output of the symbolizing tool the RTL fork() the process and redirects the streams. This is where the whole thing hangs. Note is that if I comment the sysconf(_SC_OPEN_MAX) call, then it hangs on one of the other subsequent system calls, like read() so it appears to not to be a sysconf()-specific issue. Another note is that the RTL sources refer to a specific reason about why it tries to use the syscall fork() in place of the libc's intercepted one: // Real fork() may call user callbacks registered with pthread_atfork(). pid = internal_fork(); The internal_fork() function is just the syscall: int internal_fork() { #if SANITIZER_USES_CANONICAL_LINUX_SYSCALLS return internal_syscall(SYSCALL(clone), SIGCHLD, 0); #else return internal_syscall(SYSCALL(fork)); #endif } -- You are receiving this mail because: You are the assignee for the bug.