Possible memory leak: passing int(None) to st.slider step value will crash streamlit

Can anybody else replicate this error I’m seeing? Streamlit version 0.73.0 and 0.72.0

input_step = st.number_input("Step")
my_range = st.slider("Range", 20, 120, step=int(input_step))

The preceeding code results in my chrome returning an Out of Memory error code.

No console error is logged. However, if I change the st.number_input to provide a default value for the input_step, like so:

input_step = st.number_input("Step", value=5)
my_range = st.slider("Range", 20, 120, step=int(input_step))

This code produces the desired result. Digging into the slider.py file, it seems like st.slider should be able to handle a None value with the following code, line 192:

step = DEFAULTS[data_type]["step"]

Doing a little more digging, I found that

input_step = int(st.number_input("Step"))
my_range = st.slider("Range", 20, 120, step=input_step)

will also lead to a crash but only in the st.slider line. input_step = int(st.number_input("Step")) alone isn’t enough to crash streamlit, but passing the value into a subsequent widget is. So it seems that the mistake might be mine: that I can’t pass in int(None) as a step value to the st.slider, which makes sense as it’s a type error. Perhaps catching this as a TypeError would be a good thing to add?

Title of this post has been changed accordingly (from Possible memory leak: passing input of st.number_input without a default value to a subsequent st.slider will crash streamlit)

(also, is there a forum tag for bugs? I couldn’t find one in the dropdown menu here)

Hi @Cells! Sounds like a real bug (and @Marisa_Smith confirmed with a repro). Thanks for the detailed information.

I’ve gone ahead and filed your issue as a bug in GitHub, which is where we intake bugs:

This one looks pretty straightforward so look for it to be solved potentially in the next release if all goes well. (Keeping in mind it’s the end of December and the next release probably won’t be til Jan 2021).

Thanks again for the detailed report! Helps us out a lot. :beers:


Oh wow, the team got onto that really quickly! I read through the pull request and was interested to see that it was a 0 value causing an infinite loop.

Thanks again for the detailed report! Helps us out a lot.

My pleasure! Keep up the great work :heavy_check_mark: In the future, I’ll jump onto github for any bugs I find and that’ll save @nthmost from having to copy/paste