Project

General

Profile

Actions

Bug #21146

open

VM_ASSERT(expr) gives bad bug report results when another ractor fails an assertion during printing of report

Added by luke-gru (Luke Gruber) about 1 month ago. Updated 19 days ago.

Status:
Open
Assignee:
-
Target version:
-
[ruby-core:121093]

Description

test.rb:

rs = 100.times.map do
  Ractor.new do
    cnt = rand 3
    cnt += 1 if cnt.zero?
    sleep cnt
    100.times do |i|
      if i != 0 && i % 50 == 0
        Ractor.fail_assert
      end
    end
  end
end

ractor.rb:

def self.fail_assert
  __builtin_cexpr! %q{
    VM_ASSERT(0), Qfalse
  }
end

make run

I would like to be able to see the bug report for the first failed assertion, without any output from the other ractors.

Updated by ko1 (Koichi Sasada) 20 days ago

Your patch uses RB_VM_LOCK_ENTER_NO_BARRIER but it should block normal use of rb_bug() (using rb_bug() is irregular case though).
So I think it should use simpler mechanism to synchronize rb_bug() calling. For example, introducing a global variable to avoid multiple rb_bug() calls.

(btw VM_ASSERT() calls rb_bug() if RUBY_DEBUG (or other macros) is defined, so rb_bug() is suitable for the example)

Updated by luke-gru (Luke Gruber) 19 days ago ยท Edited

Thanks for your comment. I can make it simpler, but I am a bit confused as to what I should do instead. If the first thread gets to the global variable first and enters rb_vm_bugreport, my thinking was that other threads that also try to enter this function should be blocked (mutex, sleep, etc.). Are you saying just return from the function and let the other thread continue anyway?

Also when you say use a global variable, do you mean an atomic global? I'm open to doing whatever you want, because maybe I'm overthinking it for just a debug case anyway.

Thanks again!

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0