Skip to content

Conversation

@casperisfine
Copy link
Contributor

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

cc @jhawthorn @tenderlove

Otherwise it can cause a VM crash. Won't be a problem in 3.2.1.
@jhawthorn
Copy link
Contributor

Can you elaborate on how this happens? As of 67ec8fe 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
Copy link
Contributor Author

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

@tenderlove
Copy link
Collaborator

@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
Copy link
Contributor

ivoanjo commented Jan 23, 2023

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

@byroot
Copy link
Contributor

byroot commented Jan 23, 2023

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

@tenderlove tenderlove merged commit 52d1df6 into tmm1:master Feb 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

5 participants