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

beam.smp memory usage at 140GB while debugging in VSCode #198

Open
jsermeno opened this issue Aug 28, 2024 · 3 comments
Open

beam.smp memory usage at 140GB while debugging in VSCode #198

jsermeno opened this issue Aug 28, 2024 · 3 comments

Comments

@jsermeno
Copy link

jsermeno commented Aug 28, 2024

Hi,

I've run into an issue that seems to be caused by an interaction between this library and the ElixirLS debugger. In a brand new project with no dependencies besides StreamData, debugging will hang and the beam.smp process will continue to increase in memory. It takes a few seconds to reach 10-20GB. If you let it run for 10 minutes or so it will exhaust all memory on your system.

System: Macbook Pro M3 Max 16"
OS: MacOS Sonoma 14.1

Minimal reproduction of the error: https://github.com/jsermeno/elixir_ls_debug_failure.

The offending lines of code seem to be:

defmodule ElixirLsFailureTest do
  use ExUnit.Case
  doctest ElixirLsFailure

  use ExUnit.Case
  use ExUnitProperties

  def gen_data() do
    StreamData.list_of(StreamData.fixed_map(%{
      "e" => StreamData.string(:utf8)
    }), min_length: 1, max_length: 1)
  end

  def gen_data_all() do
    gen all fixed_map <- gen_data() do
      fixed_map
    end
  end

  test "greets the world" do
    data = Enum.at(gen_data_all(), 0)
    assert ElixirLsFailure.hello() == :world
  end
end

Removing most any StreamData calls from this test case fixes the error for me and debugging continues to work normally. The issue seems to occur from the debugging interpreting the StreamData module while running this code. This means using :int.ni/1 or :int.i/1. Avoiding interpreting the StreamData module avoids this problem.

The original context for this piece of code is that StreamData.list_of() was generating values inside of another fixed_map call.

Related issue here: elixir-lsp/elixir-ls#1017

@whatyouhide
Copy link
Owner

Is ElixirLS's debugger executing any code from stream_data? Otherwise, I don't see how this could be cause by stream_data itself 😕

@whatyouhide whatyouhide changed the title Beam.smp memory usage at 140GB while debugging in VSCode. beam.smp memory usage at 140GB while debugging in VSCode Aug 28, 2024
@jsermeno
Copy link
Author

jsermeno commented Aug 29, 2024

Hi, thanks for getting back so quickly. Yes, the code executes StreamData code unless I'm missing something. The greets the world test executes and calls the gen_data_all() function which calls the gen macro from the ExUnitProperties module in order to generate test data.

test "greets the world" do
  data = Enum.at(gen_data_all(), 0)
  assert ElixirLsFailure.hello() == :world
end

This is the code from StreamData that seems to cause the issue:

def gen_data() do
  StreamData.list_of(StreamData.fixed_map(%{
    "e" => StreamData.string(:utf8)
  }), min_length: 1, max_length: 1)
end

def gen_data_all() do
  gen all fixed_map <- gen_data() do
    fixed_map
  end
end

@whatyouhide
Copy link
Owner

Right, I’m confused as to why this would only show up in ElixirLS but not in normal code. It seems to be an issue with ElixirLS, is what I’m trying to say.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants
@jsermeno @whatyouhide and others