From nobody Thu May 18 13:22:04 2023 X-Original-To: threads@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QMVxm5DzQz4BYYV for ; Thu, 18 May 2023 13:22:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QMVxm2hb9z47Nf for ; Thu, 18 May 2023 13:22:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684416124; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=O0UT/chQb6KkbJRs39rRqEq56chqKBiUwEXwUzsQiA4=; b=Cz4taf3A11PywAGT6jMQXO8bIZ128t77sUHItfRaH2iP66G3/mofn4LwGliPLMYckNnFHY 1+gygMVvQKIwu+PTYlcIVjwlRyeA5YT5ZjjM1iLNIrndo66+kRMpNCYZhjrWHRK6LpmtiN 4t3cvgk0mh75+z08EO4GD5n76BA3+2IjtLSsU4w0iIURcqhpHZkcOFMadeAewROr9msNH0 z6n06bNrKsosfPiaP+n69b5iPyXXbsF8qvv+B6+mljLp3vNNdocnJq6AE29+9ENurwscYo wmjfGNoFiLYiVIOOeLZjYKH69tUrAlzarzgQfatug9rRxeH/PWor8Rv0W4d/4A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684416124; a=rsa-sha256; cv=none; b=u5nTJFOh3RdTN9vxu8k6xKfyY2jBWzaYy7Bp9I1cIgEqLrSqwEQQc0n2MQuOhgHoAUHWEw UTGF5nds1O3ef/iLYN6d8ZAeBCREZletsg+ZDgpPLSYAMEL149cKeawdNJZtpowU9n1Pa/ UZFpkJlBuIdHvbUUKCgfD5fwhG+Qq/7M7WFQwP7iW/ueECTk2+MTCCjwv5oam7hibx3gGo 99cwGR7JYodI8AF1ebBfT449cg/qbQhRAuBKKBE2zHGKQHAiqziq4V8FlxzFcufss5P1Xr VhklENYWEwpbILilTFauJ0A2hdiaPnF3Jke787wUpsjGoTUa+rPkljW+AO7A2Q== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QMVxm1nf5zn6V for ; Thu, 18 May 2023 13:22:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 34IDM4Hi096411 for ; Thu, 18 May 2023 13:22:04 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 34IDM4v2096410 for threads@FreeBSD.org; Thu, 18 May 2023 13:22:04 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 271490] Deadlock between _rtld_atfork_pre and _thr_attr_init Date: Thu, 18 May 2023 13:22:04 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 13.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kj@kjtsanaktsidis.id.au X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Threading List-Archive: https://lists.freebsd.org/archives/freebsd-threads List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271490 Bug ID: 271490 Summary: Deadlock between _rtld_atfork_pre and _thr_attr_init Product: Base System Version: 13.2-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: threads Assignee: threads@FreeBSD.org Reporter: kj@kjtsanaktsidis.id.au Created attachment 242250 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D242250&action= =3Dedit GDB output from my stuck process I'm working on fixing some test failures in Ruby on FreeBSD, and I've found what I think is a deadlock in FreeBSD between two threads, one of which is forking and one of which is just starting. The Ruby test which does this looks something like the following: ``` require 'timeout' def test_daemon_no_threads data =3D Timeout.timeout(3) do IO.popen("-") do |f| break f.readlines.map(&:chomp) if f th =3D Thread.start { sleep 3 } Process.daemon(true, true) puts "this is sometimes never reached!" end end end ``` The test forks, and then in the child, starts a thread and then forks again (via a call to daemon(3)). On my machine, this will semi-reliably produce a deadlock inside the call to `Process.daemon` (and before the second fork actually takes place). The thread calling `daemon(3)` gets stuck acquiring locks in `_rtld_atfork_pre`, whilst the new thread (the one which is starte= d as `Thread.start { sleep 3 }` is stuck inside jemalloc's `extent_deactivate` as part of a call to `_thr_attr_init`. --- To reproduce this in the Ruby source, one can checkout the latest Ruby mast= er from github.com/ruby/ruby.git, do the autoconf/configure dance, run `make`,= and then run ``` while ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=3D.ex= t -- ./test/runner.rb test/ruby/test_process.rb -n test_daemon_no_threads; do ec= ho "ok"; done; ``` On my machine, this will eventually get stuck forever in the test.=20 n.b. - if you find the test failing for this reason - http://rubyci.s3.amazonaws.com/freebsd13/ruby-master/log/20230517T003001Z.f= ail.html.gz - that's a _different_ issue, in Ruby itself, that I am trying to fix - tha= t's how I discovered this deadlock thing... --- I've attached a pair of backtraces I got from attaching gdb to the process.= I don't really know where to go from here to debug the issue though; I can't = seem to make it happen in a similar C program, and by inspection I can't really = see why there's a deadlock at all. I can't work out why the forking thread would hold any jemalloc locks, and I _really_ can't see why the new thread would = hold any rtld locks. Any thoughts? Thanks! --=20 You are receiving this mail because: You are the assignee for the bug.=