Threaded vs. Interrupt Approach about stackprof HOT 10 CLOSED

I've run stackprof on large scale production traffic sites (like this one) without issue. Sounds like there may be a bug in the s3 library you're using, where it doesn't handle EINTR correctly and retry.

Although iirc we are using SA_RESTART so interruptions shouldn't even bubble up in the first place.

from stackprof.

Based on http://man7.org/linux/man-pages/man7/signal.7.html, it sounds like there a variety of functions that are never restarted, regardless of the use of SA_RESTART. These methods include recv and send, which are presumably used under the hood by the S3 library.

from stackprof.

What library is it?

Networking code generally loops around EINTR for this reason.

from stackprof.

https://github.com/aws/aws-sdk-ruby, specifically version 2.8.7

from stackprof.

Do you have a stack trace of the failure?

from stackprof.

The approach in stackprof was copied from gperftools, which google also uses extensively internally. If a library doesn't react well to signal interruption, it's a bug in that library.

Sampling via a thread is an interesting idea. You could do that for wall time profiling, but I'm not sure how cpu profiling would work with a thread. Either way, probably best to implement something like that in a separate project? You could do it with a ruby thread, and there might be something like that already implemented in ruby-prof or other profiler.

from stackprof.

Thanks for the really fast responses, as always :) You're a very helpful maintainer.

I'll try to dig up a stack trace later, and see if I can identify a bug in the S3 library.

If that ends up being a rabbit hole, I'll investigate other profiling libraries.

from stackprof.

Okay, I dug a little further, and on second look, I don't think it has anything to do with S3.

It seems like an interaction with the thread pool being used by https://github.com/chadrem/workers (we parallelize S3 uploads using that library).

require 'workers'
require 'stackprof'

group = Workers::TaskGroup.new
group.add { sleep(1) }
StackProf.run(mode: :wall, interval: 500, raw: true) do
  puts group.run
end
puts group.tasks[0].state

I would expect this to output:

true
suceeded

What it actually outputs is

false
running

If I remove the Stackprof.Run (so the resulting script is just this):

require 'workers'
require 'stackprof'

group = Workers::TaskGroup.new
group.add { sleep(1) }
puts group.run
puts group.tasks[0].state

Then the result is indeed

true
succeeded

I recognize that this is likely a bug with the workers library, and not with stackprof, but just figured I'd post here in case I'm wrong about that, or if you have any insights about the potential cause.

from stackprof.

Found a fix: chadrem/workers#8 (comment)

Closing this now, since this ended up having nothing to do with stackprof :)

from stackprof.

Nice find. May be worth reporting up to ruby-core too, as it seems CondVar#wait should have more sane behavior here.

from stackprof.