https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112012-04-23T22:29:10ZRuby Issue Tracking SystemRuby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261012012-04-23T22:29:10Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Feedback</i></li><li><strong>Priority</strong> changed from <i>5</i> to <i>3</i></li></ul><p>Hello,</p>
<p>NetBSD is not supported currently. A patch is welcome.</p>
<p>The following is just my guess.</p>
<p>There is a constraint in POSIX that only async-signal-safe functions<br>
can be called after fork. In many systems which conforms to POSIX,<br>
this constraint is more or less relaxed. In recent NetBSD, however,<br>
I heard that the constraint is real. To comply with it, I have no<br>
idea but prohibiting Kernel#fork in NetBSD (as well as windows).</p>
<p>Again, this is just my guess. I'm sorry if my guess is wrong.</p>
<p>--<br>
Yusuke Endoh <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a></p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261152012-04-24T00:16:51Zrudolf (r stu3)
<ul></ul><p>Thanks for the comment. I am sorry, but I don't understand the sentence "NetBSD is not supported". I can see NetBSD-related statements in configure.in, so that means, that the build infrastructure has support for NetBSD (and indeed, it builds on NetBSD). Can you please explain, what you mean with that?</p>
<p>For the problem at hand: if I understand correctly, the mentioned test (from bootstraptest/test_thread.rb) should not be run under POSIX systems?</p>
<p>I have found some related notes (<a href="https://www.opengroup.org/austin/docs/austin_446.txt" class="external">https://www.opengroup.org/austin/docs/austin_446.txt</a>) about posix_spawn() supposedly being async-signal-safe. Maybe Kernel#fork should use posix_spawn() on systems which implement this function?</p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261212012-04-24T00:46:08Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>rudolf (r stu3) wrote:</p>
<blockquote>
<p>Thanks for the comment. I am sorry, but I don't understand the sentence "NetBSD is not supported". I can see NetBSD-related statements in configure.in, so that means, that the build infrastructure has support for NetBSD (and indeed, it builds on NetBSD).</p>
</blockquote>
<p>An early NetBSD was somewhat supported.<br>
IIRC, the strong constraint I said has been employed since NetBSD 5.0+.</p>
<blockquote>
<p>Can you please explain, what you mean with that?</p>
</blockquote>
<p>See below.</p>
<p><a href="https://bugs.ruby-lang.org/projects/ruby-trunk/wiki/SupportedPlatforms" class="external">https://bugs.ruby-lang.org/projects/ruby-trunk/wiki/SupportedPlatforms</a></p>
<blockquote>
<p>For the problem at hand: if I understand correctly, the mentioned test (from bootstraptest/test_thread.rb) should not be run under POSIX systems?</p>
</blockquote>
<p>Strictly speaking, yes, I think.<br>
But the feature works and is actually useful in many "supported" platforms.<br>
So we won't remove the test.</p>
<blockquote>
<p>I have found some related notes (<a href="https://www.opengroup.org/austin/docs/austin_446.txt" class="external">https://www.opengroup.org/austin/docs/austin_446.txt</a>) about posix_spawn() supposedly being async-signal-safe. Maybe Kernel#fork should use posix_spawn() on systems which implement this function?</p>
</blockquote>
<p>posix_spawn does not substitute for fork. It is almost fork+exec.<br>
IOW, we cannot use posix_spawn to implement Kernel#fork.</p>
<p>FYI, we have Kernel#spawn already.</p>
<p>--<br>
Yusuke Endoh <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a></p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261232012-04-24T02:53:38Zkosaki (Motohiro KOSAKI)kosaki.motohiro@gmail.com
<ul></ul><p>Hello,</p>
<p>I think this is a kind of documentation issue. If you use C, you can't use both thread and fork. It's obvious.<br>
And almost people think ruby naturally has the same limitation because ruby is written by C. But rudolf implicitly<br>
pointed out some people don't think so.</p>
<p>So, if anyone send me a documentation patch, i'll merge it.</p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261262012-04-24T03:32:06Zrudolf (r stu3)
<ul></ul><p>mame (Yusuke Endoh) wrote:</p>
<blockquote>
<p>rudolf (r stu3) wrote:</p>
<blockquote>
<p>I don't understand the sentence "NetBSD is not supported". [...] Can you please explain, what you mean with that?</p>
</blockquote>
<p>See below.<br>
<a href="https://bugs.ruby-lang.org/projects/ruby-trunk/wiki/SupportedPlatforms" class="external">https://bugs.ruby-lang.org/projects/ruby-trunk/wiki/SupportedPlatforms</a></p>
</blockquote>
<p>Thanks, i was not aware of that. I'll respect that.</p>
<blockquote>
<p>FYI, we have Kernel#spawn already.</p>
</blockquote>
<p>I didn't know that, thanks.</p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261272012-04-24T03:36:05Zrudolf (r stu3)
<ul></ul><p>kosaki (Motohiro KOSAKI) wrote:</p>
<blockquote>
<p>I think this is a kind of documentation issue. If you use C, you can't use both thread and fork. It's obvious.<br>
And almost people think ruby naturally has the same limitation because ruby is written by C. But rudolf implicitly<br>
pointed out some people don't think so.</p>
<p>So, if anyone send me a documentation patch, i'll merge it.</p>
</blockquote>
<p>Yes, I agree it will help if the documentation will mention that. But the sole existence of a test which uses both thread and fork is somewhat contradictory :)</p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261292012-04-24T04:23:23Zkosaki (Motohiro KOSAKI)kosaki.motohiro@gmail.com
<ul></ul><blockquote>
<p>kosaki (Motohiro KOSAKI) wrote:</p>
<blockquote>
<p>I think this is a kind of documentation issue. If you use C, you can't use both thread and fork. It's obvious.<br>
And almost people think ruby naturally has the same limitation because ruby is written by C. But rudolf implicitly<br>
pointed out some people don't think so.</p>
<p>So, if anyone send me a documentation patch, i'll merge it.</p>
</blockquote>
<p>Yes, I agree it will help if the documentation will mention that. But the sole existence of a test which uses both thread and fork is somewhat contradictory :)</p>
</blockquote>
<p>Just add "skip if NetBSD" idiom into the test. :)<br>
Our test suite aren't intended to test posix issue, it only works for<br>
detecting unintended commit from careless commiter.</p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261332012-04-24T12:23:15Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>Hello,</p>
<p>2012/4/24, kosaki (Motohiro KOSAKI) <a href="mailto:kosaki.motohiro@gmail.com" class="email">kosaki.motohiro@gmail.com</a>:</p>
<blockquote>
<p>I think this is a kind of documentation issue. If you use C, you can't use<br>
both thread and fork. It's obvious.<br>
And almost people think ruby naturally has the same limitation because ruby<br>
is written by C. But rudolf implicitly<br>
pointed out some people don't think so.</p>
</blockquote>
<p>No, this is not documentation issue.<br>
The easy code <em>actually</em> causes SEGV on the platform, doesn't it?<br>
I'm against remaining such a significant problem and adding ad-hoc<br>
guards to the tests.</p>
<p>I suggest to make Kernel#fork raise a NotImplementedError on NetBSD<br>
5.0+.<br>
Fortunately, the tests already have a guard for NotImplementedError<br>
because there is a supported platform that does not support<br>
Kernel#fork (you know, windows).<br>
Even on the platform, SEGV is not allowed, in principle.</p>
<p>Note, my suggestion is based on my uncertain guess about NetBSD 5.0+.<br>
I'm not even a user of NetBSD. I think anyone should confirm if my<br>
guess is correct.<br>
Kosaki-san, if you seriously want to support NetBSD, I'd like you to<br>
be a platform maintainer for NetBSD.</p>
<p>--<br>
Yusuke Endoh <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a></p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261372012-04-24T12:32:09Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><p>I tried the code with NetBSD 5.1_STABLE (GENERIC) i386 Mon Oct 3 14:22:23 JST 2011 and it works.<br>
So NetBSD recently broke something around pthread.</p>
<p>As far as I know, Ruby 1.9 on NetBSD 4.0 can't fork because pthread can't mix with fork as mame and kosaki said.<br>
But NetBSD 5.0 or later seems to try to work them.<br>
(I reported such problem as kern/42772)</p>
<p>So this should be handled as Third Party's Issue, and report to NetBSD.<br>
NetBSD may fix if they treated this as a bug.</p>
<p>mame (Yusuke Endoh) wrote:</p>
<blockquote>
<p>2012/4/24, kosaki (Motohiro KOSAKI) <a href="mailto:kosaki.motohiro@gmail.com" class="email">kosaki.motohiro@gmail.com</a>:</p>
<blockquote>
<p>I think this is a kind of documentation issue. If you use C, you can't use<br>
both thread and fork. It's obvious.<br>
And almost people think ruby naturally has the same limitation because ruby<br>
is written by C. But rudolf implicitly<br>
pointed out some people don't think so.</p>
</blockquote>
<p>No, this is not documentation issue.<br>
The easy code <em>actually</em> causes SEGV on the platform, doesn't it?<br>
I'm against remaining such a significant problem and adding ad-hoc<br>
guards to the tests.</p>
</blockquote>
<p>Ruby shouldn't cause SEGV, but</p>
<blockquote>
<p>I suggest to make Kernel#fork raise a NotImplementedError on NetBSD<br>
5.0+.<br>
Fortunately, the tests already have a guard for NotImplementedError<br>
because there is a supported platform that does not support<br>
Kernel#fork (you know, windows).<br>
Even on the platform, SEGV is not allowed, in principle.</p>
<p>Note, my suggestion is based on my uncertain guess about NetBSD 5.0+.<br>
I'm not even a user of NetBSD. I think anyone should confirm if my<br>
guess is correct.<br>
Kosaki-san, if you seriously want to support NetBSD, I'd like you to<br>
be a platform maintainer for NetBSD.</p>
</blockquote>
<p>as I said above, it works with NetBSD 5.1.<br>
So this is a bug added after 5.1.</p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261392012-04-24T12:48:31Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><p>naruse (Yui NARUSE) wrote:</p>
<blockquote>
<p>as I said above, it works with NetBSD 5.1.<br>
So this is a bug added after 5.1.</p>
</blockquote>
<p>I tried it on i386-netbsdelf6.99.4 (2012-04-13), and it works.<br>
It maybe x86_64 issue, or fixed in current, or something.</p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261412012-04-24T13:23:16Zkosaki (Motohiro KOSAKI)kosaki.motohiro@gmail.com
<ul></ul><p>On Mon, Apr 23, 2012 at 11:17 PM, Yusuke Endoh <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a> wrote:</p>
<blockquote>
<p>Hello,</p>
<p>2012/4/24, kosaki (Motohiro KOSAKI) <a href="mailto:kosaki.motohiro@gmail.com" class="email">kosaki.motohiro@gmail.com</a>:</p>
<blockquote>
<p>I think this is a kind of documentation issue. If you use C, you can't use<br>
both thread and fork. It's obvious.<br>
And almost people think ruby naturally has the same limitation because ruby<br>
is written by C. But rudolf implicitly<br>
pointed out some people don't think so.</p>
</blockquote>
<p>No, this is not documentation issue.<br>
The easy code <em>actually</em> causes SEGV on the platform, doesn't it?</p>
</blockquote>
<p>Any platform may cause SEGV on such code. In fact, it's not NetBSD specific.<br>
Please think why thread+fork require async-signal-safe.</p>
<p>Do you want raise NotImplementError on <em>all</em> platform?</p>
<blockquote>
<p>I'm against remaining such a significant problem and adding ad-hoc<br>
guards to the tests.</p>
<p>I suggest to make Kernel#fork raise a NotImplementedError on NetBSD<br>
5.0+.<br>
Fortunately, the tests already have a guard for NotImplementedError<br>
because there is a supported platform that does not support<br>
Kernel#fork (you know, windows).<br>
Even on the platform, SEGV is not allowed, in principle.</p>
</blockquote>
<p>No. it works if user don't use threads. So, one option is, fork after<br>
thread.new raise<br>
an exception on all platform.</p>
<blockquote>
<p>Note, my suggestion is based on my uncertain guess about NetBSD 5.0+.<br>
I'm not even a user of NetBSD. I think anyone should confirm if my<br>
guess is correct.<br>
Kosaki-san, if you seriously want to support NetBSD, I'd like you to<br>
be a platform maintainer for NetBSD.</p>
</blockquote>
<p>Nope. I'm not NetBSD user.</p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261472012-04-24T16:58:03Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><p>kosaki (Motohiro KOSAKI) wrote:</p>
<blockquote>
<p>On Mon, Apr 23, 2012 at 11:17 PM, Yusuke Endoh <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a> wrote:</p>
<blockquote>
<p>I suggest to make Kernel#fork raise a NotImplementedError on NetBSD<br>
5.0+.<br>
Fortunately, the tests already have a guard for NotImplementedError<br>
because there is a supported platform that does not support<br>
Kernel#fork (you know, windows).<br>
Even on the platform, SEGV is not allowed, in principle.</p>
</blockquote>
<p>No. it works if user don't use threads. So, one option is, fork after<br>
thread.new raise an exception on all platform.</p>
</blockquote>
<p>It is wrong.<br>
Ruby 1.9 makes timer thread even if there is only the main thread.</p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261502012-04-24T18:27:27Zrudolf (r stu3)
<ul></ul><p>I am not sure if the following information are relevant, but I want you to have a complete picture.</p>
<p>I've tried to bring this issue on NetBSD maillist and I've got the following reply (<a href="http://mail-index.netbsd.org/current-users/2012/04/22/msg019961.html" class="external">http://mail-index.netbsd.org/current-users/2012/04/22/msg019961.html</a>):<br>
``Memory faults in any malloc implementation are mostly due to bugs is the application (use after free, overwrite end/start allocated buffer, etc).''</p>
<p>When trying with rubinius (yesterday's git snapshot of master branch), it survives without a hiccup.</p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261512012-04-24T19:53:19Zkosaki (Motohiro KOSAKI)kosaki.motohiro@gmail.com
<ul></ul><blockquote>
<p>kosaki (Motohiro KOSAKI) wrote:</p>
<blockquote>
<p>On Mon, Apr 23, 2012 at 11:17 PM, Yusuke Endoh <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a> wrote:<br>
> I suggest to make Kernel#fork raise a NotImplementedError on NetBSD<br>
> 5.0+.<br>
> Fortunately, the tests already have a guard for NotImplementedError<br>
> because there is a supported platform that does not support<br>
> Kernel#fork (you know, windows).<br>
> Even on the platform, SEGV is not allowed, in principle.</p>
<p> No. it works if user don't use threads. So, one option is, fork after<br>
thread.new raise an exception on all platform.</p>
</blockquote>
<p>It is wrong.<br>
Ruby 1.9 makes timer thread even if there is only the main thread.</p>
</blockquote>
<p>You don't understand the issue. On other OSs, async-signal-unsafe function usage<br>
makes unlocked libc lock issue. therefore our current fork code works.<br>
It kill timer thread<br>
at once.</p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261522012-04-24T19:59:18Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>Hello,</p>
<p>2012/4/24, KOSAKI Motohiro <a href="mailto:kosaki.motohiro@gmail.com" class="email">kosaki.motohiro@gmail.com</a>:</p>
<blockquote>
<p>Do you want raise NotImplementError on <em>all</em> platform?</p>
</blockquote>
<p>My answer is yes, if the problem occurs actually.</p>
<blockquote>
<p>So, one option is, fork after thread.new raise<br>
an exception on all platform.</p>
</blockquote>
<p>Looks good.</p>
<blockquote>
<blockquote>
<p>Note, my suggestion is based on my uncertain guess about NetBSD 5.0+.<br>
I'm not even a user of NetBSD. I think anyone should confirm if my<br>
guess is correct.<br>
Kosaki-san, if you seriously want to support NetBSD, I'd like you to<br>
be a platform maintainer for NetBSD.</p>
</blockquote>
<p>Nope. I'm not NetBSD user.</p>
</blockquote>
<p>Why do all the tests need to be passed on a platform that<br>
there is no maintainer for?</p>
<p>--<br>
Yusuke Endoh <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a></p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261672012-04-25T00:29:21Zkosaki (Motohiro KOSAKI)kosaki.motohiro@gmail.com
<ul></ul><p>(4/24/12 6:55 AM), Yusuke Endoh wrote:</p>
<blockquote>
<p>Hello,</p>
<p>2012/4/24, KOSAKI Motohiro<a href="mailto:kosaki.motohiro@gmail.com" class="email">kosaki.motohiro@gmail.com</a>:</p>
<blockquote>
<p>Do you want raise NotImplementError on <em>all</em> platform?</p>
</blockquote>
<p>My answer is yes, if the problem occurs actually.</p>
<blockquote>
<p>So, one option is, fork after thread.new raise<br>
an exception on all platform.</p>
</blockquote>
<p>Looks good.</p>
</blockquote>
<p>okey. at first, I'd like to add a warnings and observe how much apps<br>
makes whiny.</p>
<blockquote>
<blockquote>
<blockquote>
<p>Note, my suggestion is based on my uncertain guess about NetBSD 5.0+.<br>
I'm not even a user of NetBSD. I think anyone should confirm if my<br>
guess is correct.<br>
Kosaki-san, if you seriously want to support NetBSD, I'd like you to<br>
be a platform maintainer for NetBSD.</p>
</blockquote>
<p>Nope. I'm not NetBSD user.</p>
</blockquote>
<p>Why do all the tests need to be passed on a platform that<br>
there is no maintainer for?</p>
</blockquote>
<p>I think, no maintainer != we should ignore such platform. It only mean<br>
we care a little than supported one.</p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261682012-04-25T01:23:21Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><p>(2012/04/24 19:44), KOSAKI Motohiro wrote:</p>
<blockquote>
<blockquote>
<p>kosaki (Motohiro KOSAKI) wrote:</p>
<blockquote>
<p>On Mon, Apr 23, 2012 at 11:17 PM, Yusuke Endoh <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a> wrote:</p>
<blockquote>
<p>I suggest to make Kernel#fork raise a NotImplementedError on NetBSD<br>
5.0+.<br>
Fortunately, the tests already have a guard for NotImplementedError<br>
because there is a supported platform that does not support<br>
Kernel#fork (you know, windows).<br>
Even on the platform, SEGV is not allowed, in principle.</p>
</blockquote>
<p>No. it works if user don't use threads. So, one option is, fork after<br>
thread.new raise an exception on all platform.</p>
</blockquote>
<p>It is wrong.<br>
Ruby 1.9 makes timer thread even if there is only the main thread.</p>
</blockquote>
<p>You don't understand the issue. On other OSs, async-signal-unsafe function usage<br>
makes unlocked libc lock issue. therefore our current fork code works.<br>
It kill timer thread<br>
at once.</p>
</blockquote>
<p>You don't know the original issue, what you are saying seems recent one.<br>
see also <a href="http://bugs.ruby-lang.org/issues/show/270" class="external">http://bugs.ruby-lang.org/issues/show/270</a></p>
<p>--<br>
NARUSE, Yui <a href="mailto:naruse@airemix.jp" class="email">naruse@airemix.jp</a></p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261702012-04-25T01:53:17Zkosaki (Motohiro KOSAKI)kosaki.motohiro@gmail.com
<ul></ul><p>On Tue, Apr 24, 2012 at 12:13 PM, NARUSE, Yui <a href="mailto:naruse@airemix.jp" class="email">naruse@airemix.jp</a> wrote:</p>
<blockquote>
<p>(2012/04/24 19:44), KOSAKI Motohiro wrote:</p>
<blockquote>
<blockquote>
<p>kosaki (Motohiro KOSAKI) wrote:</p>
<blockquote>
<p>On Mon, Apr 23, 2012 at 11:17 PM, Yusuke Endoh <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a> wrote:<br>
> I suggest to make Kernel#fork raise a NotImplementedError on NetBSD<br>
> 5.0+.<br>
> Fortunately, the tests already have a guard for NotImplementedError<br>
> because there is a supported platform that does not support<br>
> Kernel#fork (you know, windows).<br>
> Even on the platform, SEGV is not allowed, in principle.</p>
<p> No. it works if user don't use threads. So, one option is, fork after<br>
thread.new raise an exception on all platform.</p>
</blockquote>
<p>It is wrong.<br>
Ruby 1.9 makes timer thread even if there is only the main thread.</p>
</blockquote>
<p>You don't understand the issue. On other OSs, async-signal-unsafe function usage<br>
makes unlocked libc lock issue. therefore our current fork code works.<br>
It kill timer thread<br>
at once.</p>
</blockquote>
<p>You don't know the original issue, what you are saying seems recent one.<br>
see also <a href="http://bugs.ruby-lang.org/issues/show/270" class="external">http://bugs.ruby-lang.org/issues/show/270</a></p>
</blockquote>
<p>I don't? Why? Even though I joined bug#270 discussion.</p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261712012-04-25T03:29:14Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p>KOSAKI Motohiro <a href="mailto:kosaki.motohiro@gmail.com" class="email">kosaki.motohiro@gmail.com</a> wrote:</p>
<blockquote>
<p>(4/24/12 6:55 AM), Yusuke Endoh wrote:</p>
<blockquote>
<p>2012/4/24, KOSAKI Motohiro<a href="mailto:kosaki.motohiro@gmail.com" class="email">kosaki.motohiro@gmail.com</a>:</p>
<blockquote>
<p>Do you want raise NotImplementError on <em>all</em> platform?</p>
</blockquote>
<p>My answer is yes, if the problem occurs actually.</p>
<blockquote>
<p>So, one option is, fork after thread.new raise<br>
an exception on all platform.</p>
</blockquote>
<p>Looks good.</p>
</blockquote>
<p>okey. at first, I'd like to add a warnings and observe how much apps<br>
makes whiny.</p>
</blockquote>
<p>Shouldn't the presence of the GVL allow Thread.new + fork to be safe in<br>
pure Ruby code? Also, the async-signal-safe requirement for fork() may<br>
be dropped in future versions of POSIX:<br>
<a href="http://austingroupbugs.net/view.php?id=62" class="external">http://austingroupbugs.net/view.php?id=62</a></p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261772012-04-25T06:23:22Zkosaki (Motohiro KOSAKI)kosaki.motohiro@gmail.com
<ul></ul><p>On Tue, Apr 24, 2012 at 2:25 PM, Eric Wong <a href="mailto:normalperson@yhbt.net" class="email">normalperson@yhbt.net</a> wrote:</p>
<blockquote>
<p>KOSAKI Motohiro <a href="mailto:kosaki.motohiro@gmail.com" class="email">kosaki.motohiro@gmail.com</a> wrote:</p>
<blockquote>
<p>(4/24/12 6:55 AM), Yusuke Endoh wrote:</p>
<blockquote>
<p>2012/4/24, KOSAKI Motohiro<a href="mailto:kosaki.motohiro@gmail.com" class="email">kosaki.motohiro@gmail.com</a>:</p>
<blockquote>
<p>Do you want raise NotImplementError on <em>all</em> platform?</p>
</blockquote>
<p>My answer is yes, if the problem occurs actually.</p>
<blockquote>
<p>So, one option is, fork after thread.new raise<br>
an exception on all platform.</p>
</blockquote>
<p>Looks good.</p>
</blockquote>
<p>okey. at first, I'd like to add a warnings and observe how much apps<br>
makes whiny.</p>
</blockquote>
<p>Shouldn't the presence of the GVL allow Thread.new + fork to be safe in<br>
pure Ruby code? Also, the async-signal-safe requirement for fork() may<br>
be dropped in future versions of POSIX:<br>
<a href="http://austingroupbugs.net/view.php?id=62" class="external">http://austingroupbugs.net/view.php?id=62</a></p>
</blockquote>
<p>I think you misunderstand this URL. Currently fork() itself is one of<br>
async-signal-safe function (i.e. can be called from signal handler).<br>
but it shouldn't.<br>
Linux and any other OSs can implement it because we have pthead_atfork(),<br>
therefore austin plan to remove the lie statement. We still can't call<br>
async-signal-safe function after fork on multi-threads enviroment.</p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=261792012-04-25T07:50:10Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><p>Following patch to NetBSD fixes this issue.<br>
thanks @_enami</p>
<a name="Index-pthreadc"></a>
<h1 >Index: pthread.c<a href="#Index-pthreadc" class="wiki-anchor">¶</a></h1>
<p>RCS file: /cvsroot/src/lib/libpthread/pthread.c,v<br>
retrieving revision 1.133<br>
diff -u -p -r1.133 pthread.c<br>
--- pthread.c 22 Mar 2012 20:01:18 -0000 1.133<br>
+++ pthread.c 24 Apr 2012 16:15:55 -0000<br>
@@ -240,7 +240,7 @@ pthread__fork_callback(void)<br>
struct __pthread_st *self;</p>
<pre><code> /* lwpctl state is not copied across fork. */
</code></pre>
<ul>
<li>
<pre><code> if (_lwp_ctl(LWPCTL_FEATURE_CURCPU, &pthread__first->pt_lwpctl)) {
</code></pre>
</li>
</ul>
<ul>
<li>
<pre><code> if (_lwp_ctl(LWPCTL_FEATURE_CURCPU, &pthread_self()->pt_lwpctl)) {
err(1, "_lwp_ctl");
}
self = pthread__self();
</code></pre>
</li>
</ul> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=262002012-04-26T03:24:04Zrudolf (r stu3)
<ul></ul><p>naruse (Yui NARUSE) wrote:</p>
<blockquote>
<p>Following patch to NetBSD fixes this issue.<br>
thanks @_enami<br>
[...]</p>
</blockquote>
<p>I've tested the patch and can no more reproduce the problem. Thanks!</p> Ruby master - Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.joinhttps://bugs.ruby-lang.org/issues/6341?journal_id=262052012-04-26T11:18:20Znaruse (Yui NARUSE)naruse@airemix.jp
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Third Party's Issue</i></li></ul><p>rudolf (r stu3) wrote:</p>
<blockquote>
<p>naruse (Yui NARUSE) wrote:</p>
<blockquote>
<p>Following patch to NetBSD fixes this issue.<br>
thanks @_enami<br>
[...]</p>
</blockquote>
<p>I've tested the patch and can no more reproduce the problem. Thanks!</p>
</blockquote>
<p>enami committed it to NetBSD current as rev 1.134.<br>
<a href="http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpthread/pthread.c?rev=1.134&content-type=text/x-cvsweb-markup&only_with_tag=MAIN" class="external">http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpthread/pthread.c?rev=1.134&content-type=text/x-cvsweb-markup&only_with_tag=MAIN</a><br>
Thank you for reporting!</p>