Bug #5240

Hang when using threads + forks on Debian GNU/kFreeBSD

Added by Lucas Nussbaum over 2 years ago. Updated over 1 year ago.

[ruby-core:39146]
Status:Feedback
Priority:Normal
Assignee:Koichi Sasada
Category:-
Target version:next minor
ruby -v:- Backport:

Description

Hi,

The following test script (derived from a test in bootstraptest/test_fork.rb)
hangs very frequently on Debian GNU/kFreeBSD:
<----
fork { }
puts "after fork"
t = Thread.start { fork{ } }
puts "after fork in thread"
t.join
puts "after join"
--->

Using git bisect, I determined that the commit introducing that regression is
SVN revision 32244:
- that revision hangs
- 32243 does not hang

This bug makes 1.9.3 unsuitable for being uploaded to Debian. So it would be
great if it was fixed before the release. Also, there are other test failures
that I'd like to analyze (but I can't because of that one), so I feel quite
worried about this.

rb-th.diff Magnifier (1.79 KB) Petr Salinger, 08/30/2011 03:08 PM

rb-main.diff Magnifier (430 Bytes) Petr Salinger, 08/30/2011 03:08 PM

History

#1 Updated by Motohiro KOSAKI over 2 years ago

  • Status changed from Open to Feedback
  • Target version set to 2.0.0

Please send us an analysis and a patch.

#2 Updated by Lucas Nussbaum over 2 years ago

I'm sorry, I'm not familiar with that code at all.

What I can provide is a kfreebsd amd64 qemu image inside which it is easy to reproduce the problem (I used it to bisect).

#3 Updated by Petr Salinger over 2 years ago

I looked at the change and in general should work even for our slightly broken pthread semantic on GNU/kFreeBSD.
It should be possible to workaround it by encapsulating timerthreadpipeownerproces usage, as shown
in first attached diff. We need to put somewhere during initialization

pthreadatfork(NULL, NULL, timerthreadchildat_fork)

Even on fully conforming pthread implementation might be GNU/kFreeBSD variant better,
as getpid() might be costly system call.

The problem is that place in main.c (as shown in 2nd diff) does not link.
Please could you advice where to put this part of code. After that I would like to test it, whether it really works for us as expected.

Please advice me.

#4 Updated by Lucas Nussbaum over 2 years ago

Dear Ruby developers,

Could you comment on Petr Salinger's patch, and especially about where to put the pthread_atfork() call?

Thanks

#5 Updated by Motohiro KOSAKI over 2 years ago

  • Status changed from Feedback to Assigned
  • Assignee set to Koichi Sasada

sasada-san, could you please tell us your opinion?

#6 Updated by Koichi Sasada over 2 years ago

  • ruby -v changed from 1.9.3 to -

Hi,

(2011/08/29 23:08), Petr Salinger wrote:

The problem is that place in main.c (as shown in 2nd diff) does not link.
Please could you advice where to put this part of code. After that I would like to test it, whether it really works for us as expected.

Please advice me.

How about to add pthreadatfork() at rbthreadcreatetimer_thread()?

--
// SASADA Koichi at atdot dot net

#7 Updated by Koichi Sasada over 1 year ago

  • Status changed from Assigned to Feedback
  • Target version changed from 2.0.0 to next minor

Also available in: Atom PDF