Closed igor-makarov closed 3 years ago
@ioquatix upon further inspection, this doesn't seem to be limited to macOS, attaching Linux run: https://github.com/CocoaPods/Core/runs/1848931012?check_suite_focus=true
@ioquatix I've managed to figure out the issue somehow - it was Internet#close
that was causing segfaults due to a race condition in how we were calling it.
Just to check, you aren't using the same internet object on different threads right?
I haven't been creating new threads, does any operation in async
or async-http
create threads?
Nope.
Can you compare the performance between calling Internet#close
and not? It should make better use of persistent connections without it.
Funny thing, if I remove the close it hangs for some reason.
Can you tell me how to reproduce it.
I'm not really sure - it's become quite a complex system but we do lots of HTTP2 calls inside a Sync
block, then lots in another Sync
block, an so on. I'll try to build a demo some time in the future.
@ioquatix I've made a repro of the hanging code - please note that this doesn't segfault. https://github.com/igor-makarov/DemoAsyncHttp
@ioquatix I think the culprit is the redirect - am I using it wrong?
@ioquatix Please note that I've manage to reduce the example further. The hang seems to occur only when redirecting, and only if the Sync { }
block is invoked more than once.
Thanks, I will take a look.
@igor-makarov this issue should be fixed in the latest release of async
and async-pool
. Can you please update and try it out?
@ioquatix looks like it got resolved! Thank you!
Hi @ioquatix !
I'm not sure what has changed, but I've got a persistent crash (segfault) in
async
while trying it with the CocoaPods experiments.It has been working before.
I've tried rolling back the versions of
async
,async-http
,nio4r
and the rest ofasync-*
. I've also tried using Ruby 3. None of these things helped. Also, the tests on these repos run fine on my machine, so this isn't segfault caught by any of them.I've recently updated macOS to 11.2, so that may be related.
Forcing
NIO4R_PURE=true
works around the problem, so it's definitely something in the native extension.I'm pretty confused.
I'm attaching the most verbose stack trace I can.