You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Big thanks for ruby_memcheck. I've been setting it up to run in CI for the datadog gem (the profiling stuff especially has a lot of native code).
I am happy to report that (so far) I don't have any wins to report ;) ;) ;)
I would like to ask for a small feature: Adding support for controlling valgrind's --fair-sched option.
Right now I'm using the escape hatch RubyMemcheck.config(valgrind_options: ['--fair-sched=yes']) to set it.
Why this option? In several cases, our test suite assumes multi-threaded behavior (because, e.g. the profiler runs in parallel with the Ruby app), and in some cases we run stuff in forks; by default valgrind forces everything to run sequentially (there's a joke in here about adding an even more global GVL somewhere...). This makes some of our specs fail (usually with timeouts) or hang (because they busy-loop in a few cases) as they would on a single-core machine.
Using this setting makes these tests pass and saves us from manually needing to maintain a list of excluded tests just for ruby_memtest.
Thanks again! 🙇
The text was updated successfully, but these errors were encountered:
The [`ruby_memcheck`](https://github.com/Shopify/ruby_memcheck) gem
provides a Ruby-specific user-friendly wrapper around valgrind.
In some cases, some of our tests were hanging or timing out due
to how valgrind runs code in a sequential manner. I've added a
new tag to be able to skip such tests.
I also explored using valgrind's `fair-sched` option
(see Shopify/ruby_memcheck#51) but ran
into issues with its output being incomplete, so decided to go
the skip route instead.
You can run the new job with `bundle exec rake spec:profiling:memcheck`.
Hey 👋
Big thanks for
ruby_memcheck
. I've been setting it up to run in CI for thedatadog
gem (the profiling stuff especially has a lot of native code).I am happy to report that (so far) I don't have any wins to report ;) ;) ;)
I would like to ask for a small feature: Adding support for controlling valgrind's
--fair-sched
option.Right now I'm using the escape hatch
RubyMemcheck.config(valgrind_options: ['--fair-sched=yes'])
to set it.Why this option? In several cases, our test suite assumes multi-threaded behavior (because, e.g. the profiler runs in parallel with the Ruby app), and in some cases we run stuff in forks; by default valgrind forces everything to run sequentially (there's a joke in here about adding an even more global GVL somewhere...). This makes some of our specs fail (usually with timeouts) or hang (because they busy-loop in a few cases) as they would on a single-core machine.
Using this setting makes these tests pass and saves us from manually needing to maintain a list of excluded tests just for ruby_memtest.
Thanks again! 🙇
The text was updated successfully, but these errors were encountered: