search

tmm1 / stackprof

a sampling call-stack profiler for ruby 2.2+
MIT License
2.09k stars 128 forks source link

Use postponed jobs on Ruby 3.2.0 #196

Closed casperisfine closed 1 year ago

casperisfine commented 1 year ago

Otherwise it can cause a VM crash. Won't be a problem in 3.2.1.

cc @jhawthorn @tenderlove

jhawthorn commented 1 year ago

Can you elaborate on how this happens? As of 67ec8fe92c8c8578311be3d8f795a34003f5f79a we should be forwarding to the thread which stackprof was started from, I'd think that would sidestep the issue (we know that thread has a stack because we ran code to start stackprof).

casperisfine commented 1 year ago

@jhawthorn I don't particularly understand the bug myself, all I know if that there is a race condition fixed by https://github.com/ruby/ruby/pull/7116. I'm sure @tenderlove or @XrXr can actually explain the issue.

tenderlove commented 1 year ago

@jhawthorn I'm not 100% sure how it's happening. I agree it's odd since we should be forwarding the signal to only active and live threads, but the core files we recovered definitely showed the ec was not fully set up. Maybe there is a race condition when threads switch?

Regardless of the root cause, I think we should merge this. At least it buys us time to figure out a stable repro.

ivoanjo commented 1 year ago

@jhawthorn maybe the issue is in mode: :cpu, not mode: :wall?

byroot commented 1 year ago

Yes, I forgot to mention that the crash only happens in CPU mode.