Project

General

Profile

Actions

Bug #19387

open

Issue with ObjectSpace.each_objects not returning objects after starting a ractor

Added by luke-gru (Luke Gruber) about 1 year ago. Updated about 2 months ago.

Status:
Open
Target version:
-
[ruby-core:112091]

Description

r = Ractor.new do
  receive # block, the problem is not the termination of the ractor but the starting
end

ObjectSpace.each_object(IO) { |io|
  p io # we get no objects
}

Updated by luke-gru (Luke Gruber) about 1 year ago

  • Subject changed from Issue with ObjectSpace.each_objects not returning IO objects after starting a ractor to Issue with ObjectSpace.each_objects not returning objects after starting a ractor

The problem is actually for any objects, not just IO.

PR here: https://github.com/ruby/ruby/pull/7191

Edit: I took down the PR because I realized it doesn't properly fix the issue. The only way to get this working, and also to get ObjectSpace._id2ref working, is to keep the RACTOR_BELONGING_ID in all builds, and use that info when letting ractors access the objects.

I'll create another PR with that in mind. But I'm wondering why was this only in debug builds? Does it have to do with speed?

Updated by hsbt (Hiroshi SHIBATA) about 1 year ago

  • Status changed from Open to Assigned
  • Assignee set to ko1 (Koichi Sasada)
Actions #3

Updated by Anonymous 6 months ago

  • Status changed from Assigned to Closed

Applied in changeset git|c08fdc68383ee368c18e15e298502e6ee0089e18.


Allow waitpid(-1) to be woken if a waitpid(pid) call is pending

If two threads are running, with one calling waitpid(-1), and another
calling waitpid($some_pid), and then $some_other_pid exits, we would
expect the waitpid(-1) call to retrieve that exit status; however, it
cannot actually do so until $some_pid also exits.

This patch fixes the issue by unconditionally checking for pending
process group waits on SIGCHLD, and then allowing pending pid-only waits
to "steal" the notification.

[Fixes #19387]

Updated by ko1 (Koichi Sasada) 6 months ago

  • Status changed from Closed to Assigned

c08fdc68383ee368c18e15e298502e6ee0089e18 is not related to this ticket.

Actions #5

Updated by Anonymous 6 months ago

  • Status changed from Assigned to Closed

Applied in changeset git|0b7a4fbaa9c56d2c67d00d86c69f9e5c71803267.


Allow waitpid(-1) to be woken if a waitpid(pid) call is pending

If two threads are running, with one calling waitpid(-1), and another
calling waitpid($some_pid), and then $some_other_pid exits, we would
expect the waitpid(-1) call to retrieve that exit status; however, it
cannot actually do so until $some_pid also exits.

This patch fixes the issue by unconditionally checking for pending
process group waits on SIGCHLD, and then allowing pending pid-only waits
to "steal" the notification.

[Fixes #19387]

Updated by luke-gru (Luke Gruber) about 2 months ago

  • ruby -v set to 3.3.0

I believe this was closed prematurely due to an unrelated git commit that wrongly tagged it. Please reopen :)

Actions #7

Updated by jeremyevans0 (Jeremy Evans) about 2 months ago

  • Status changed from Closed to Open
Actions #8

Updated by Anonymous about 2 months ago

  • Status changed from Open to Closed

Applied in changeset git|76a8c963c7ad975b7bbfc1c4979bf7a2de15af27.


Add a test for what happens with concurent calls to waitpid

Ruby 3.1 and 3.2 have a bug in their implementation, for which I'm
backporting a fix. However, the current development branch doesn't have
the issue (because the MJIT -> RJIT change refactored how waitpid worked
substantially). I do however want to commit the test which verifies
that waitpid works properly on master.

[Fixes #19387]

Updated by luke-gru (Luke Gruber) about 2 months ago

It happened again :( I notified the committer of the mistake. Please reopen, thanks!

Actions #10

Updated by jeremyevans0 (Jeremy Evans) about 2 months ago

  • Status changed from Closed to Open
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0