General

Profile

benweint (Ben Weintraub)

  • Login: benweint
  • Email: benweint@gmail.com
  • Registered on: 01/22/2013
  • Last sign in: 08/15/2016

Issues

open closed Total
Assigned issues 0 0 0
Reported issues 0 6 6

Activity

08/15/2016

10:21 PM Ruby Bug #12678 (Closed): No way to set a timeout for TLS handshake when using Net::SMTP
When establishing a connection to an SMTP server, Net::SMTP doesn't offer a way to specify a timeout for how long the TLS handshake should take.
In our production environment, this means we routinely see hangs under this callstack:
...
benweint (Ben Weintraub)

08/02/2015

07:09 PM Ruby Bug #11411 (Closed): Crash in rb_gc_mark() during Rails app boot with GC.stress=1
When booting a newly-initialized Rails 4.2.1 app under Ruby 2.2.2 with `GC.stress` enabled, I get a repeatable crash. The same crash happens at least as far back as 2.1.4 (haven't tried any earlier versions).
Steps to reproduce:
1....
benweint (Ben Weintraub)

10/28/2014

07:03 PM Ruby Bug #10443: Forking with contended mutex held can lead to deadlock in child process upon unlock
The original test case was not actually minimal (there's no need to attempt to re-acquire the lock in the forked child process in order to demonstrate the issue), so I'm attaching an updated version. benweint (Ben Weintraub)
03:42 PM Ruby Bug #10443 (Closed): Forking with contended mutex held can lead to deadlock in child process upon unlock
If a Ruby thread calls `Process.fork` while holding a Mutex (for example, within a `Mutex#synchronize` block) that is also concurrently being contended for by a background thread, the thread in the child process will occasionally be unab... benweint (Ben Weintraub)

03/14/2014

08:44 PM Ruby Bug #9629: GC::Profiler.total_time under-reports GC time compared to dtrace GC probe measurement
One minor follow-up: it's actually not that getrusage takes a 'long' time (relative to the cost of each lazy sweep invocation), it's the dtrace probes themselves firing. The conclusion remains the same, though GC::Profiler seems correct. benweint (Ben Weintraub)

03/13/2014

10:53 PM Ruby Bug #9629: GC::Profiler.total_time under-reports GC time compared to dtrace GC probe measurement
I think I've figured out the discrepancy here: the dtrace probes wrap around the getrusage(2) calls that GC::Profiler bases its timings on for Mac OS X. The average lazy sweep time is quite short (single-digit microseconds per lazy sweep... benweint (Ben Weintraub)
04:57 AM Ruby Bug #9629: GC::Profiler.total_time under-reports GC time compared to dtrace GC probe measurement
I realized that these are actually measuring different things: dtrace's timestamps measure wall clock time, whereas GC::Profiler on Mac OS X uses getrusage, which measures user CPU time. It still seems weird that the two would be so dive... benweint (Ben Weintraub)
12:40 AM Ruby Bug #9629: GC::Profiler.total_time under-reports GC time compared to dtrace GC probe measurement
Worth noting: a quick read through gc.c suggested that the missing GC sweep time might be due to me not having built with GC_PROFILE_MORE_DETAIL, but even after building with that, I still see the same discrepancy where GC::Profiler is s... benweint (Ben Weintraub)
12:31 AM Ruby Bug #9629: GC::Profiler.total_time under-reports GC time compared to dtrace GC probe measurement
Uploading the two files from that gist, just to keep everything in one place. benweint (Ben Weintraub)
12:30 AM Ruby Bug #9629 (Closed): GC::Profiler.total_time under-reports GC time compared to dtrace GC probe measurement
I'm trying to square the numbers that I'm getting from GC::Profiler.total_time against those that I'm getting out of instrumentation with the GC dtrace probes embedded in Ruby, and having a hard time getting the two sources to agree.
...
benweint (Ben Weintraub)

Also available in: Atom