Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix: Backend config initializer to_existing_atom calls fixed #87

Merged
merged 2 commits into from
Feb 23, 2024

Conversation

njwest
Copy link
Contributor

@njwest njwest commented Feb 20, 2024

Fixes #85 , tests passing locally.

The bug comes from this code in the supervisor:

  # Multiple backends
  def init(config) when is_list(config) do
    children =
      Enum.map(config, fn {k, c} ->
        "hammer_backend_#{k}_pool"
        |> String.to_existing_atom()
        |> to_pool_spec(c)
      end)

    Supervisor.init(children, strategy: :one_for_one)
  end

String.to_existing_atom/1 is trying to create atoms that do not exist at runtime. Replacing this with String.to_atom/1 does the trick.

String.to_atom/1 is naughty in cases in which dynamic user input is being atomized or when a number of values being atomized are dynamic or large for some other reason because we have a finite number of atoms available to us on the BEAM, but this is neither of those cases.

Because the atom being created in this code is from user configuration, String.to_existing_atom/1 isn't necessary here because it is highly unlikely someone will DDoS their atom memory from their own user configuration of Hammer, as that would require passing a list of hundreds of thousands to millions of backends to their Hammer configuration, an unlikely case that indicates a bigger problem outside of the code.

An alternative solution to this would be instantiating a list of possible atoms prior to this and using them in a way in which they don't get swept away, which would mean updating the list of usable backends in Hammer's source whenever someone develops a new one, a rather limiting condition.

@njwest njwest changed the title to_existing_atom converted to to_atom Fix: Backend config initializer to_existing_atom converted to to_atom Feb 20, 2024
@njwest njwest changed the title Fix: Backend config initializer to_existing_atom converted to to_atom Fix: Backend config initializer to_existing_atoms Feb 21, 2024
@njwest njwest changed the title Fix: Backend config initializer to_existing_atoms Fix: Backend config initializer to_existing_atom calls fixed Feb 21, 2024
@njwest
Copy link
Contributor Author

njwest commented Feb 21, 2024

this now also fixes #88

@epinault
Copy link
Contributor

So the tests are failing. We will need to disable that rule

Copy link
Contributor

@epinault epinault left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated credo rule in master so that should be fine

@epinault epinault merged commit f34a3a5 into ExHammer:master Feb 23, 2024
0 of 22 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Crash on Application startup with String.to_existing_atom
2 participants