Streamlit terminating abruptly when logger.level is set to debug

Using Streamlit
, ,
1

Hi,

I am evaluating Streamlit and trying to run the application locally. I want to have the debug logs from Streamlit so I tried the --logger.level debug but Streamlit stops abruptly without any errors.

Code

import streamlit as st

st.write("TEST")

Streamlit execution,

C:\streamlit_code>py -3.9 -m streamlit run --logger.level debug test.py
2024-08-29 21:04:57.810 Starting server...
2024-08-29 21:04:57.810 Serving static content from C:\Python39\lib\site-packages\streamlit\static
2024-08-29 21:04:57.810 Server started on port 8501
2024-08-29 21:04:57.810 Runtime state: RuntimeState.INITIAL -> RuntimeState.NO_SESSIONS_CONNECTED

  You can now view your Streamlit app in your browser.

  Local URL: http://localhost:8501
  Network URL: http://10.10.10.10:8501

2024-08-29 21:04:57.841 Setting up signal handler
2024-08-29 21:04:58.657 No singleton. Registering one.
2024-08-29 21:04:58.660 Watcher created for C:\streamlit_code\pages
2024-08-29 21:04:58.661 Watcher created for C:\streamlit_code\test.py
2024-08-29 21:04:58.661 AppSession initialized (id=f9076d8c-849b-4006-9785-1037682e69a8)
2024-08-29 21:04:58.661 Created new session for client 1754932815760. Session ID: f9076d8c-849b-4006-9785-1037682e69a8
2024-08-29 21:04:58.662 Runtime state: RuntimeState.NO_SESSIONS_CONNECTED -> RuntimeState.ONE_OR_MORE_SESSIONS_CONNECTED

C:\streamlit_code>

Streamlit version: 1.38.0
Python version: 3.9, 3.10
OS: Windows 10

1 Like
2

Reproducible with python 3.12. It doesn’t happen in Linux, though.

3

Glad to find this, was pulling my hair out. Windows also.
Using --server.headless true allows the app to stay up until a browser hits it.

I’m curious if you can also reproduce my simple Streamlit terminates when using st.feedback

4

Does this also happen with 1.37 or is this a new issue that started to appear with 1.38?

5

I’m having this issue right now, using windows. This happens on 1.38, 1.37, 1.36. Any other version to test?

Python: 3.11.9
OS: Windows 11

1 Like
6

Thanks @idealize-okay-rule! Could you please share the Python version you were using and any other possibly relevant parameters such as the example app and exact command you have used to start the Streamlit app?

7

ui/ui.py

import streamlit as st


st.text("Hello World")

Command:

streamlit run .\ui\ui.py --logger.level=debug

Output:


(d:\(omitted)\.conda) PS D:\(omitted)> streamlit run .\ui\ui.py --logger.level=debug                                                      
2024-09-03 09:48:45.105 Starting server...
2024-09-03 09:48:45.114 Serving static content from d:\(omitted)\.conda\Lib\site-packages\streamlit\static        
2024-09-03 09:48:45.115 Server started on port 8501
2024-09-03 09:48:45.115 Runtime state: RuntimeState.INITIAL -> RuntimeState.NO_SESSIONS_CONNECTED

  You can now view your Streamlit app in your browser.

  Local URL: http://localhost:8501
  Network URL: http://192.168.2.183:8501

2024-09-03 09:48:45.297 Setting up signal handler
2024-09-03 09:48:46.156 No singleton. Registering one.
2024-09-03 09:48:46.156 Watcher created for D:\(omitted)\ui\pages
2024-09-03 09:48:46.160 Watcher created for D:\(omitted)\ui\ui.py
2024-09-03 09:48:46.160 AppSession initialized (id=9974e654-15f0-4541-abb3-c6fd7ec2347f)
2024-09-03 09:48:46.160 Created new session for client 2062176018384. Session ID: 9974e654-15f0-4541-abb3-c6fd7ec2347f
2024-09-03 09:48:46.160 Runtime state: RuntimeState.NO_SESSIONS_CONNECTED -> RuntimeState.ONE_OR_MORE_SESSIONS_CONNECTED
(d:\(omitted)\.conda) PS D:\(omitted)>

image
image859Ă—393 6.97 KB

Never showed “Hello world”. Streamlit, version 1.36.0 (Oldest I could run right now without dependency issues in my project)

1 Like
8

The crash seems to happen about here:

image
image849Ă—371 23.5 KB

Here is the payload: b'Z\x08\n\x00\x12\x00\x1a\x00"\x00'

image

print(BackMsg().ParseFromString(payload))

gives 10

Trying to instantiate BackMsg() and store it to a variable makes the program unstable at this point (though I can print like above). So it’s very unlikely protobuf’s BackMsg’s fault.

Here is the line: (Not the same version)

The “Received the following back message” message is never printed.

2 Likes
9

You can comment every occurence of _LOGGER in browser_websocket_handler as a workaround. More specifically commenting this line lets you see “Hello world”

_LOGGER.debug("Received the following back message:\n%s", msg)

It seems it’s not safe to call _LOGGER inside the on_message callback. It also seems to be the case if you replace _LOGGER.debug("Received the following back message:\n%s", msg) with print(msg). The issue seems likely to be due to either trying to read msg or doing I/O inside on_message.

EDIT: It’s not due to I/O alone, reading the msg variable causes a crash, but otherwise it seems to be fine:

            #_LOGGER.debug("Received the following back message:\n%s", msg)
            _LOGGER.debug("Received the following back message:\n")
            print("Hello")

EDIT (Reproduction):

Trying to trigger a string representation __repr__ of BackMsg causes a crash. Here’s a reproduction:

from streamlit.proto.BackMsg_pb2 import BackMsg

print("Start")
BackMsg().__repr__() # Crashes
print("End")

However, commenting the first print still works:

from streamlit.proto.BackMsg_pb2 import BackMsg

#print("Start")
test = BackMsg().__repr__() #Does not crash
print("Test: ", test, "end") #Test:   end

Also happens with ButtonGroupProto used by st.feedback:

from streamlit.proto.ButtonGroup_pb2 import ButtonGroup as ButtonGroupProto

print("Start")
test = ButtonGroupProto().__repr__() # Crashes
print("Test: ", test, "end")
10

Hey y’all, this seems to be an issue with the newest protobuf release (see this GitHub thread) on Windows. For me, downgrading to protobuf 5.27.0 fixed the issue: pip install protobuf==5.27.0 .
It’d be great if you could try it out and report back here whether this also fixes the issue on your end :slightly_smiling_face:

1 Like
11

Yes, downgrading to 5.27.0 fixed the feedback issue!

1 Like