Crash tracker spawning long-running child processes?

[luc-financeit]

Current behaviour

Upgrading the datadog gem from 2.2.0 to 2.3.0 causes a spec in our test suite to hang. The code being tested does something like

6.times do
  Process.fork { ... }
end

Process.waitall # Hangs

Looking at ps output, there's a libdatadog-crashtracking-receiver child process which our waitall is hung up on — manually killing the crashtracker process, or disabling the crashtracker entirely (via DD_CRASHTRACKING_ENABLED) allows the test to complete successfully.

F   UID     PID    PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
4     0     328       0  20   0  16460  7680 -      Ss   ?          0:00 bash -l
4     0     557     328  20   0 190964 29656 -      Sl   ?          0:00  \_ ruby /usr/local/rvm/gems/ruby-3.1.6/bin/parallel_rspec --verbose spec
4     0     559     557  20   0 1414052 518752 -    Sl   ?          1:18      \_ ruby bin/rspec -O .rspec_parallel spec/the_hanging_spec.rb
0     0     560     559  20   0  24128  3844 -      S    ?          0:00          \_ /usr/local/rvm/gems/ruby-3.1.6/gems/libdatadog-11.0.0.1.0-x86_64-linux/vendor/libdatadog-11.0.0/x86_64-linux/libdatadog-x86_64-unknown-linux-gnu/bin/libdatadog-crashtracking-receiver 

Expected behaviour

No hang.

Steps to reproduce

I'm afraid I don't have a stand-alone reproduction — the actual code is significantly more complicated, and I haven't tried slimming it down to see if there's additional triggers. I can dig in to it more if the above isn't enough to go on.

Environment

• datadog version: 2.3.0
• Configuration block (Datadog.configure ...): See gist.
• Ruby version: 3.1.6
• Operating system: Amazon Linux 2
• Relevant library versions: N/A