julismz

Binary memory leak with Bandit and SSL

I’m having some memory leaks with bandit and SSL. I think that the ssl_server_session_cache_sup is the problem:

:recon.bin_leak(2)
[
  {#PID<0.23353.0>, -1962,
   [
     current_function: {:gen_server, :loop, 7},
     initial_call: {:proc_lib, :init_p, 5}
   ]},
  {#PID<0.23269.0>, -138,
   [
     current_function: {:gen_server, :loop, 7},
     initial_call: {:proc_lib, :init_p, 5}
   ]}
]

And then:

Process.info(pid)
[
  current_function: {:gen_server, :loop, 7},
  initial_call: {:proc_lib, :init_p, 5},
  status: :waiting,
  message_queue_len: 0,
  links: [#PID<0.2531.0>],
  dictionary: [
    "$initial_call": {:ssl_server_session_cache, :init, 1},
    "$ancestors": [:ssl_server_session_cache_sup, :tls_server_sup, :tls_sup,
     :ssl_connection_sup, :ssl_sup, #PID<0.2516.0>],
    "$process_label": {:pre_tls_13_server_session_cache, #Port<0.10518>}
  ],
  trap_exit: true,
  error_handler: :error_handler,
  priority: :normal,
  group_leader: #PID<0.2515.0>,
  total_heap_size: 365872,
  heap_size: 46422,
  stack_size: 11,
  reductions: 34846448,
  garbage_collection: [
    max_heap_size: %{
      error_logger: true,
      include_shared_binaries: false,
      kill: true,
      size: 0
    },
    min_bin_vheap_size: 376,
    min_heap_size: 376,
    fullsweep_after: 10,
    minor_gcs: 1
  ],
  suspending: []
]

After running :recon.bin_leak(2)the RAM reduce from 85% to ~35%…

Extra info that might be useful:

+sbwt long
+sbwtdcpu long
+sbwtdio long
ERL_FULLSWEEP_AFTER 10

Is there some way to collect that garbage or avoid the SSL cache? Could it have some negative effect?

9 comments

#ssl #bandit

3 509 9

2025-10-28 10:12:13 UTC

Most Liked

jhogberg

Erlang Core Team

Thanks for reporting this!

Try passing the +Muatags code emulator flag and then paste the full result of running :instrument.allocations(%{ :flags => [:per_mfa] }) during the ”leak” in a post (or DM if you feel it’s sensitive). That’ll hopefully tell us what specific code is the culprit, and give us a better idea of how to handle this.

Post #1

jhogberg

Erlang Core Team

Oh and another run, without +Muatags code and the :per_process flag instead of :per_mfa, before and after :recon.bin_leak(2) would also be good.

Post #9

jhogberg

Erlang Core Team

Thanks, here’s a summary (in bytes) of where the binaries were allocated, I’ve omitted those under 100K:

[{90877952,{crypto,aead_cipher_nif,7}},
 {68285824,{ssl,send,2}},
 {63921152,{'Foo.Helper',decode_term,1}},
 {51442432,{ssl_record,do_cipher_aead,4}},
 {27113472,tcp_inet},
 {12791808,{crypto,ec_generate_key_nif,2}},
 {7997952,{'Registry',register,3}},
 {7348480,{erlang,put,2}},
 {7123072,{erts_internal,garbage_collect,1}},
 {7060096,{gen,reply,2}},
 {4428288,{'Bandit.WebSocket.Frame',deserialize,2}},
 {4423424,{'String','valid?',2}},
 {4197888,
  {'Bandit.WebSocket.Frame',header_and_payload_length,2}},
 {2719232,{'Plug.HTML',to_iodata,4}},
 {2301440,{erlang,prepare_loading_1,2}},
 {2164736,system},
 {1015808,
  {'Redix.Protocol','-parse_string_of_known_size/3-fun-1-',4}},
 {543872,{gen,do_call,4}},
 {423808,{unicode,characters_to_binary,1}},
 {314368,prim_file},
 {134144,{'Redix.SocketOwner',handle_info,2}},
 {108544,{pubkey_pem,decode_pem_entry,2}}]

It doesn’t look much like it’s the session cache that is the problem, it appears more likely that the offending binaries are “smeared” over the entire system. Try doing this again, running the command before and after :recon.bin_leak(2)

Post #8