You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
defmoduleElixirLsFailureTestdouseExUnit.CasedoctestElixirLsFailureuseExUnit.CaseuseExUnitPropertiesdefgen_data()doStreamData.list_of(StreamData.fixed_map(%{"e"=>StreamData.string(:utf8)}),min_length: 1,max_length: 1)enddefgen_data_all()dogenallfixed_map<-gen_data()dofixed_mapendendtest"greets the world"dodata=Enum.at(gen_data_all(),0)assertElixirLsFailure.hello()==:worldendend
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.
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
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"dodata=Enum.at(gen_data_all(),0)assertElixirLsFailure.hello()==:worldend
This is the code from StreamData that seems to cause the issue:
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.
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:
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 anotherfixed_map
call.Related issue here: elixir-lsp/elixir-ls#1017
The text was updated successfully, but these errors were encountered: