Textual app silently crashes without printing exception to stdout

[traverseda]

Workaround

I can't reproduce this when the dev console is attached. You can open the dev console in one terminal using textual console and launch your app with textual run --dev <yourprogram.py> in order to (probably) work around this issue.

---

import json
from pathlib import Path

from rich.text import Text

from textual.app import App, ComposeResult
from textual.widgets import Header, Footer, Static

class TreeApp(App):

    BINDINGS = [
        ("a", "add", "Add node"),
    ]

    def compose(self) -> ComposeResult:
        yield Header()
        yield Footer()
        yield Static("Press A to crash")

    def action_add(self) -> None:
        raise Exception("This error should print")

if __name__ == "__main__":
    app = TreeApp()
    app.run()

Open app, press A, no output on stdout. Weirdly I did get stdout errors once or twice, so apologies for the heisenbug. If you can't reproduce this I'll try posting my frozen dependencies and all that.

# Textual Diagnostics

## Versions

| Name    | Value  |
|---------|--------|
| Textual | 0.14.0 |
| Rich    | 13.3.2 |

## Python

| Name           | Value                                                                                  |
|----------------|----------------------------------------------------------------------------------------|
| Version        | 3.10.9                                                                                 |
| Implementation | CPython                                                                                |
| Compiler       | GCC 12.2.0                                                                             |
| Executable     | /home/traverseda/.cache/pypoetry/virtualenvs/pyadminconsole-Ykr_Mx4S-py3.10/bin/python |

## Operating System

| Name    | Value                                                      |
|---------|------------------------------------------------------------|
| System  | Linux                                                      |
| Release | 6.2.2-zen1-1-zen                                           |
| Version | #1 ZEN SMP PREEMPT_DYNAMIC Fri, 03 Mar 2023 15:58:29 +0000 |

## Terminal

| Name                 | Value          |
|----------------------|----------------|
| Terminal Application | *Unknown*      |
| TERM                 | xterm-256color |
| COLORTERM            | truecolor      |
| FORCE_COLOR          | *Not set*      |
| NO_COLOR             | *Not set*      |

## Rich Console options

| Name           | Value                |
|----------------|----------------------|
| size           | width=236, height=55 |
| legacy_windows | False                |
| min_width      | 1                    |
| max_width      | 236                  |
| is_terminal    | True                 |
| encoding       | utf-8                |
| max_height     | 55                   |
| justify        | None                 |
| overflow       | None                 |
| no_wrap        | False                |
| highlight      | None                 |
| markup         | None                 |
| height         | None                 |

[willmcgugan]

Works every time for me.

[davep]

I get a crash every time here too, both running directly, and with textual run.

Textual Diagnostics

Versions

Name	Value
Textual	0.14.0
Rich	13.3.2

Python

Name	Value
Version	3.10.10
Implementation	CPython
Compiler	Clang 14.0.0 (clang-1400.0.29.202)
Executable	/Users/davep/develop/python/textual-sandbox/.venv/bin/python

Operating System

Name	Value
System	Darwin
Release	22.3.0
Version	Darwin Kernel Version 22.3.0: Mon Jan 30 20:42:11 PST 2023; root:xnu-8792.81.3~2/RELEASE_X86_64

Terminal

Name	Value
Terminal Application	iTerm.app (3.4.19)
TERM	xterm-256color
COLORTERM	truecolor
FORCE_COLOR	Not set
NO_COLOR	Not set

Rich Console options

Name	Value
size	width=158, height=81
legacy_windows	False
min_width	1
max_width	158
is_terminal	False
encoding	utf-8
max_height	81
justify	None
overflow	None
no_wrap	False
highlight	None
markup	None
height	None

[traverseda]

Well frig. Tried it in bash (instead of zsh) and it worked exactly once.

[willmcgugan]

Dave gets the error every time, as expected. My textual diagnose will be identical.

[traverseda]

Ah yeah I misread that, sorry

[traverseda]

Does not appear to be env variable related as env -i poetry run python example.py does not cause errors to show up again.

Nice heisenbug, not sure how to deal with it if no one else can reproduce it though. Setting PYTHONDONTWRITEBYTECODE=1 allows me to more clearly demonstrate that it's some sort of race condition. Without that it consistently doesn't show the error except maybe the first time it's run.

[traverseda]

Here's my exact requirements if that helps

click==8.1.3
ghp-import==2.1.0
importlib-metadata==4.13.0
Jinja2==3.1.2
linkify-it-py==2.0.0
Markdown==3.3.7
markdown-it-py==2.2.0
MarkupSafe==2.1.2
mdit-py-plugins==0.3.5
mdurl==0.1.2
mergedeep==1.3.4
mkdocs==1.4.2
mkdocs-exclude==1.0.2
packaging==23.0
Pygments==2.14.0
python-dateutil==2.8.2
PyYAML==6.0
pyyaml_env_tag==0.1
rich==13.3.2
six==1.16.0
textual==0.14.0
typing_extensions==4.5.0
uc-micro-py==1.0.1
watchdog==2.3.1
zipp==3.15.0

Really not sure that there's anything more that can be done.

[traverseda]

So it turns out that what's making this consistently print out errors is having the dev console attached. That's why I thought it was a feature of running with --dev because it never happens when the dev console is running. Which is unfortunate as the dev console could hopefully help be track down the issue.

[traverseda]

Well this looks like a pretty nasty race conditions, let me know if you need any help but I think that's about all I can provide. I'm doing this on a Dell G15 with an 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz in it, which I suspect is more powerful that the macbooks you're using unless one of them is an m1 or something.

If you do anything to try and reduce race conditions let me know and I'll try running it on my laptop to see if it's gotten fixed, but I'm sure at some point one of you will start being able to reproduce it :p

[davep]

unless one of them is an m1 or something

MacBook Pros with M1.

[traverseda]

Huh, I was confused by RELEASE_X86_64 in the kernel parameters but I'm not really a MacOs guy. Maybe you can try emulating a slower CPU in order to replicate this?

Maybe try using cpulimit -l 200 -i if that works on m1 macs ?

It's not exactly a big deal of a bug, there's a work around (attach dev console) and it doesn't really effect program functionality, but I have a feeling it's going to come back to bite you in a really annoying way sometimes down the line.

[davep]

RELEASE_X86_64

I have two MacBook Pros. One an older Intel, one an M1.

[willmcgugan]

@traverseda What terminal are you running, and have you tried running it on anything else?

[traverseda]

Konsole (KDE built in terminal). I can also reproduce this in alacritty.

[davep]

To update: #2033 is in v0.15 and might be worth trying out.

[traverseda]

Afraid that didn't do it

[willmcgugan]

Fixed in v0.19.0

[github-actions]

Don't forget to star the repository!

Follow @textualizeio for Textual updates.

[ofek]

what was the fix?

[willmcgugan]

Flushing stdout before writing the traceback.