Unfortunately I still get the same error in the non-test project (not fiber_blocker). I've included `<ruby/fiber/scheduler.h>`. No compiler warnings regarding `rb_fiber_scheduler_*` but it still crashes when `rb_fiber_scheduler_unblock(s...paddor (Patrik Wenger)
You're right. It was line 28, the one with `rb_fiber_scheduler_block(scheduler, blocker, timeout)`. I just ran it again with the commit I just pushed (which enables the bad line in the test `#test_fiber_blocking_in_ext` on line 44): ...paddor (Patrik Wenger)
Thanks for looking into this. I'm pretty sure it was that one (initial) commit in the fiber_blocker repo. My extension (a PR for the rbnng gem [1]) would ideally block/unblock fibers using NNG's `nng_aio_*()` functions [2]. That's how I ...paddor (Patrik Wenger)
While trying to manually block/unblock fibers from an extension using the Fiber Scheduler, I noticed that using the return value of `rb_fiber_scheduler_current()` crashes Ruby. I've created a minimal extension gem called "fiber_block...paddor (Patrik Wenger)
hsbt (Hiroshi SHIBATA) wrote in #note-2: > It's intentional changes. see https://bugs.ruby-lang.org/issues/18797 Thanks. nobu (Nobuyoshi Nakada) wrote in #note-3: > ... Yeah that would be nice.paddor (Patrik Wenger)
Regexp.new used to take up to 3 arguments, but now only 1..2 are allowed: ``` [1] pry(main)> Regexp.new 'abc', 'i', 'n' ArgumentError: wrong number of arguments (given 3, expected 1..2) from (pry):1:in `initialize' ``` On 3.2...paddor (Patrik Wenger)
Wow, I just figured out something. It's the env variable `GEM_PATH` from my system that leaks into the process being run (duh). For some reason I thought that snap processes were more isolated. If I `env -i` (ignore environment) first, i...paddor (Patrik Wenger)
paddor (Patrik Wenger)05:38 PM Ruby Bug #20155: Using value of rb_fiber_scheduler_current() crashes Ruby