Bug: Allocation in GC warning suppression proc blocks process

[jzakiya]

System: System76 laptop; i7-67000HQ, 4C|8T; 2.6-3.5 GHz; 16GB mem; Linux 5.15.13.

Running some code with 1.3.0 I found a bug in multi-threading that ran fine with 1.2.2.

Here's the code: https://gist.github.com/jzakiya/2b65b609f091dcbb6f792f16c63a8ac4

Here's how its compiled: crystal build twinprimes_ssoz.cr -Dpreview_mt --release

Here are some inputs that show working and non-working examples.

This input works: CRYSTAL_WORKERS=8 ./twinprimes_ssoz 50000000000000000 50000000019000000

This input hangs: CRYSTAL_WORKERS=8 ./twinprimes_ssoz 50000000000000000 50000000119000000

[jzakiya]

I see it runs when setting CRYSTAL_WORKERS to 1 or 2 but hangs for higher values.

[straight-shoota]

I can confirm this on my machine. The example where the input hangs issues a GC warning on 1.2 but that's been disabled in 1.3 (#11289). It also really saturates all cores for a while on 1.2. But on 1.3 there's a short initial burst, then the threads seem to sit idle. So something's blocking.

It's interesting that it works for CRYSTAL_WORKERS=2.
For CRYSTAL_WORKERS=3 I get one more line of output (1 of 15 twinpairs done) before the program stalls.

[straight-shoota]

Actually #11289 seems to be the culprit. Reverting that change makes the program run successfully on 1.3.0.

I think the reason is this:

crystal/src/gc/boehm.cr

Line 135 in a3ee70c

format_string = String.new(msg)

The call to String.new allocates a new string. I'm pretty sure that's not a good idea inside an allocation warning hook. 🤦‍♂️

[jzakiya]

Thanks @straight-shoota for quickly tracking this down and fixing.

Will there be a 1.3.1 to include this, et al, fixes before 1.4.0?

[straight-shoota]

Yes, this regression should land in 1.3.1.

[jzakiya]

Thank you!

[yxhuvud]

🤦‍♂️ Argh. I should have seen that was an issue.

[straight-shoota]

Yeah we all missed that despite C bindings needing extra care (especially without specs) 🙈