dudalev
commented
1 day ago I was able to produce similar crashdump backtraces (stuck in crypto:supports/0) with this snippet (and -heart added to vm opts)
1> application:ensure_all_started(gun), lists:foreach(fun(_) -> spawn_link(fun() ->
TLSOpts = [{verify, verify_none}, {cacerts, public_key:cacerts_get()}],
WSOpts = #{ keepalive => 3000, silence_pings => false},
{ok, ConnPid} = gun:open("echo.websocket.org", 443, #{tls_opts => TLSOpts, ws_opts => WSOpts}),
{ok, _} = gun:await_up(ConnPid), StreamRef = gun:ws_upgrade(ConnPid, "/"),
{upgrade, [<<"websocket">>], _} = gun:await(ConnPid, StreamRef, 3000),
gun:ws_send(ConnPid, StreamRef, {text, <<"BOOM">>}),
gun:await(ConnPid, StreamRef, 5000)
end) end, lists:seq(1, 100000)).
heart: Tue Oct 22 15:16:49 2024: heart-beat time-out, no activity for 65 seconds
heart: Tue Oct 22 15:16:49 2024: Would reboot. Terminating.
Kernel pid terminated (heart) ({port_terminated,{heart,loop,[<0.0.0>,{state,#Port<0.1>,[],[],undefined}]}})
Crash dump is being written to: erl_crash.dump...done
frej
flaviogrossi
xadhoom
dgud
sverker
In a simple websocket streams consumer app (ten workers under one supervisor), one of the vm schedulers occasionally (but not rarely) gets blocked in a nif called from crypto module. That in turn leads to tcp app getting into a bad state, node not responding (but seemingly running) and all that kind of trouble. Oddly enough, if it fails, it always happens with the last (10th) worker to reach the connecting code.
Still working on a minimal example that I can upload here, but it all looks like this:
In a SIGUSR1-generated crash dump, two processes active - the first one is blocked, the second one is the one that called halt().
The process stack always looks like this:
When running BEAM with debug, it's quite likely that gdb gives me the offending function:
Relevant version info:
The connecting code is pretty simple:
Not sure if the whole thing is caused by some ssl compat issues, but some workaround advice would be much appreciated.