ETS tables unexpectedly stop existing

int32

hey, I’m working on an implementation of the Reticulum Network Stack in elixir. however, I have a strange bug that seems to have appeared out of nowhere: when I run it using mix run -e "RNS.Reticulum.start_link()" --no-halt, I get this output:

Compiling 1 file (.ex)
     warning: variable "source" is unused (if the variable is not meant to be used, prefix it with an underscore)
     │
 448 │       {:inbound, packet, source} ->
     │                          ~
     │
     └─ lib/rns/packet.ex:448:26: RNS.Packet.wait_for_proof/3

Generated rns app

17:29:58.536 [debug] The config file does not contain 'transport'. We will instead use the default value, which is false(disabled).

17:29:58.541 [debug] The config file does not contain 'data_directory'. We will instead use the default value, which is '~/.local/share/reticulum_ex/'.

17:29:58.542 [info] RNS is starting...

17:29:58.562 [debug] Starting interface RNS.Interface.TCPClient with parameters %{"host" => "202.61.243.41", "port" => 4965}...

17:29:58.575 [debug] Interface GenDestination#<6b9f66014d9853faab220fba47d02761> started with pid #PID<0.191.0>

17:29:58.576 [warning] Interface with pid #PID<0.191.0> and id "GenDestination#<6b9f66014d9853faab220fba47d02761>" has exited with reason :shutdown!

17:29:58.646 [debug] Interface TCPClient@202.61.243.41:4965 started with pid #PID<0.192.0>

17:30:00.080 [error] GenServer #PID<0.192.0> terminating
** (ArgumentError) errors were found at the given arguments:

  * 1st argument: the table identifier does not refer to an existing ETS table

    (stdlib 7.1) :ets.member(:packet_hashes, <<110, 88, 109, 8, 49, 139, 206, 247, 78, 43, 81, 190, 92, 0, 35, 150, 18, 130, 108, 79, 1, 25, 167, 1, 191, 114, 235, 23, 112, 226, 244, 72>>)
    (rns 0.1.0) lib/rns/packet_hash_store.ex:32: RNS.PacketHashStore.exists?/1
    (rns 0.1.0) lib/rns/packet_handler.ex:28: RNS.PacketHandler.start/3
    (rns 0.1.0) lib/rns/interface/tcp_client.ex:81: RNS.Interface.TCPClient.handle_info/2
    (stdlib 7.1) gen_server.erl:2434: :gen_server.try_handle_info/3
    (stdlib 7.1) gen_server.erl:2420: :gen_server.handle_msg/3
    (stdlib 7.1) proc_lib.erl:333: :proc_lib.init_p_do_apply/3
Last message: {:tcp, #Port<0.9>, <<126, 81, 2, 55, 62, 77, 215, 139, 61, 49, 156, 165, 232, 81, 188, 237, 168, 25, 133, 188, 73, 236, 11, 4, 111, 1, 18, 35, 183, 192, 70, 227, 194, 22, 90, 0, 144, 60, 127, 114, 193, 25, 155, 71, 6, 159, 246, 237, 187, 141, 105, 92, 65, 92, 251, 102, 31, 114, 49, 54, 213, 64, 245, 185, 217, 12, 179, 112, 13, 176, 104, 80, 11, 81, 35, 5, 142, 104, 198, 225, 147, 107, 213, 81, 23, 33, 122, 168, 169, 240, 34, 128, 125, 94, 202, 46, 255, ...>>}
State: {{:interface, "TCPClient@202.61.243.41:4965", #PID<0.192.0>, :full, nil, false}, #Port<0.9>, false}

here’s the code snippet of the creation of the ETS table:

:ets.new(:packet_hashes, [
    {:read_concurrency, true},
    {:write_concurrency, true},
    :public,
    :named_table
  ])

see the full code

this happens when a packet is received. the ETS table doesn’t seem to exist, but I have confirmed(with IO.inspect()) that the ETS table is created and does exist for some time, but later, it disappears.
the simplest explanation would be that the process died, but I have a supervisor supervising it and I did not get any error messages.
I have managed to re-create the table in IEX before the first packet was received, and I got an error for yet another ETS table, so it would seem that this has happened to all ETS tables.

can anyone tell me what the heck is going on or do I need to call an exorcist?

18 comments

#ets #troubleshooting

0 569 18

2026-01-01 11:28:20 UTC

Showing Posts 1 to 10

Show Best Posts
Show All Posts (oldest first)
Show All Posts (newest first)

jswanner

Do you have the same trouble with RNS.AnnounceHashStore? I ask because it’s a GenServer, which is the way I would normally create this kind of process (while the process giving you trouble is using spawn_link and Process.sleep(:infinity)). I’m wondering if the owning process tied up sleeping is the cause of the problem

Post #1

jswanner

Also, welcome @int32!

Post #2

int32

I have tried making RNS.PacketHashStore a GenServer and the problem remains.
here’s the code of RNS.PacketHashStore as a GenServer:

defmodule RNS.PacketHashStore do
  @moduledoc """
  Stores the hashes of all sent/received packets.
  This is to be sure no packets are received twice, and also limits attacks on announces which could be used to block some paths.
  """

  use GenServer

  @spec start_link(any()) :: {:ok, pid()}
  def start_link(opts) do
    GenServer.start_link(__MODULE__, opts)
  end

  # Client
  @doc "Adds a packet hash."
  @spec add(RNS.Packet.hash()) :: :ok
  def add(packet_hash) do
    true = :ets.insert(:packet_hashes, {packet_hash})
    :ok
  end

  @doc "Checks if the packet hash is in the table."
  @spec exists?(RNS.Packet.hash()) :: boolean()
  def exists?(packet_hash) do
    :ets.member(:packet_hashes, packet_hash)
  end

  # Callbacks
  @impl true
  @spec init(any()) :: {:ok, nil}
  def init(_opts) do
    :ets.new(:packet_hashes, [
      {:read_concurrency, true},
      {:write_concurrency, true},
      :public,
      :named_table
    ])

    {:ok, nil}
  end
end

do you think making it a GenServer is better(not for the bug, just as a general question)? as it doesn’t listen to anything, I’m not sure it makes sense of having it as a GenServer, I might even remove the process and make RNS.Reticulum create the table instead.

Post #3