[#8136] Confused exception handling in Continuation Context — "Robert Dober" <robert.dober@...>

Hi all

13 messages 2006/07/06

[#8248] One-Click Installer: MinGW? or VC2005? — "Curt Hibbs" <ml.chibbs@...>

I just posted this to ruby-talk. But I would also like to discuss this

33 messages 2006/07/18
[#8264] Re: One-Click Installer: MinGW? or VC2005? — Charlie Savage <cfis@...> 2006/07/19

From my experience using both tool chains on Windows (for the ruby-prof

[#8266] Re: One-Click Installer: MinGW? or VC2005? — "Curt Hibbs" <ml.chibbs@...> 2006/07/19

Tim, I'm going to top reply since your post was so long. I'm interested in

[#8267] Re: One-Click Installer: MinGW? or VC2005? — Charlie Savage <cfis@...> 2006/07/19

> Tim, I'm going to top reply since your post was so long. I'm interested in

[#8271] my sandboxing extension!! — why the lucky stiff <ruby-core@...>

I have (what feels like) very exciting news. I finally sat down to code up my

17 messages 2006/07/19

[#8430] Re: doc patch: weakref. — "Berger, Daniel" <Daniel.Berger@...>

> -----Original Message-----

19 messages 2006/07/28
[#8434] Re: doc patch: weakref. — Yukihiro Matsumoto <matz@...> 2006/07/29

Hi,

[#8436] Re: doc patch: weakref. — Daniel Berger <djberg96@...> 2006/07/29

Yukihiro Matsumoto wrote:

[#8437] Re: doc patch: weakref. — Mauricio Fernandez <mfp@...> 2006/07/29

On Sat, Jul 29, 2006 at 07:37:24PM +0900, Daniel Berger wrote:

[#8441] Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...>

I have the following code:

18 messages 2006/07/30
[#8442] Re: Inconsistency in scoping during module_eval? — nobu@... 2006/07/30

Hi,

[#8443] Re: Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...> 2006/07/30

Why does this:

[#8445] Re: Inconsistency in scoping during module_eval? — Yukihiro Matsumoto <matz@...> 2006/07/30

Hi,

[#8454] Re: Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...> 2006/07/31

So to clarify...

[ ruby-Patches-5111 ] Instability around popen due to missing rb_thread_atfork

From: <noreply@...>
Date: 2006-07-18 21:36:13 UTC
List: ruby-core #8262
Patches item #5111, was opened at 2006-07-18 22:36
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1700&aid=5111&group_id=426

Category: Ruby1.8
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jonathan Paisley (jzp)
Assigned to: Nobody (None)
Summary: Instability around popen due to missing rb_thread_atfork

Initial Comment:
A Ruby program with multiple threads making calls to IO.popen (or indirectly via backticks) can get some nasty race conditions if existing threads get a chance to run in the child.

This can happen, for example, if the rb_warn("Insecure world writable dir...") from file.c:path_check_0() gets invoked in the child.

Solution is to add a call to 'rb_thread_atfork()' in the child after fork() in order to kill off those other threads.

On a related theme, it seems like the 'rb_proc_exec' in process.c:pipe_open() should be protected with rb_protect or similar, to prevent any exceptions raised during rb_proc_exec() from being propagated to the soon-to-be-dead main thread in the child process. I'm not familiar enough with use of rb_protect to provide a proper patch for that.


Patch attached and included inline below:


diff -ur orig/ruby/io.c ruby/io.c
--- orig/ruby/io.c	2006-06-26 08:23:47.000000000 +0100
+++ ruby/io.c	2006-07-18 22:27:33.000000000 +0100
@@ -3102,6 +3102,7 @@
   retry:
     switch ((pid = fork())) {
       case 0:			/* child */
+	rb_thread_atfork();
 	if (modef & FMODE_READABLE) {
 	    close(pr[0]);
 	    if (pr[1] != 1) {


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1700&aid=5111&group_id=426

In This Thread

Prev Next