Repository navigation
Closed
Labels
Description
Bug Report
Some code I was working on last week is causing mypy to segfault. I tried retracing my steps to find the change that broke mypy, without luck.
Config:
- Platform: macOS 12.4 on M1
- Arch: arm64
- Python: 3.9.13
- mypy: 0.971
- mypy plugins: none (segfault happens with all plugins disabled and is not linked to any imported modules)
mypy --tb and mypy --pdb are segfaulting without any info. gdb is not available on arm64. I get a bit more info using faulthandler, but all it indicates is the file:
$ python -X faulthandler -m mypy -v .
…
LOG: Processing SCC singleton (coaster.views.classview) as inherently stale with stale deps (__future__ asyncio builtins coaster coaster.auth coaster.sqlalchemy coaster.typing coaster.utils coaster.views.misc flask flask.blueprints flask.typing functools sqlalchemy.orm.attributes sqlalchemy.orm.descriptor_props sqlalchemy.orm.mapper sqlalchemy.orm.properties sqlalchemy.orm.query types typing typing_extensions werkzeug.local werkzeug.routing werkzeug.wrappers)
Fatal Python error: Segmentation fault
Current thread 0x0000000102f10580 (most recent call first):
File "/Users/jace/.virtualenvs/hasgeek/lib/python3.9/site-packages/mypy/__main__.py", line 12 in console_entry
File "/Users/jace/.virtualenvs/hasgeek/lib/python3.9/site-packages/mypy/__main__.py", line 34 in <module>
File "/opt/homebrew/Cellar/python@3.9/3.9.13_2/Frameworks/Python.framework/Versions/3.9/lib/python3.9/runpy.py", line 87 in _run_code
File "/opt/homebrew/Cellar/python@3.9/3.9.13_2/Frameworks/Python.framework/Versions/3.9/lib/python3.9/runpy.py", line 197 in _run_module_as_main
[1] 44130 segmentation fault python -X faulthandler -m mypy -v .
The file in question is located at https://github.com/hasgeek/coaster/blob/369ce391f11850f10fc0ab42a52c196188436a50/coaster/views/classview.py
To Reproduce
git clone https://github.com/hasgeek/coaster.gitcd coastergit checkout 369ce391f11850f10fc0ab42a52c196188436a50mypy coaster/views/classview.py
Activity
hauntsaninja commentedon Aug 18, 2022
Thanks, I needed to disable the "sqlmypy" plugin in order to be able to repro.
When running with uncompiled mypy (using latest master), I get the following stacktrace:
Details
ilevkivskyi commentedon Aug 24, 2022
Probably another example of issue caused by
expand_type()callingmake_simplified_union(). I was recently thinking about this but still don't have a good solution.jace commentedon Sep 5, 2022
Is there a particular type declaration in my code that's causing this? Type checking is broken downstream for me because of this one file. I have to test my client apps with the import removed from env (using a pre-commit container), which sucks because there's no type checking against this library's exports.
hauntsaninja commentedon Sep 5, 2022
You can avoid the crash by doing:
Didn't yet look into minimising it.
You can also get mypy to avoid processing a single module by doing something like the following in your mypy config:
ilevkivskyi commentedon Sep 5, 2022
A simple repro test case is
Actually, looking at this, the bug is that we never push to assumptions stack for callback subtyping, while we should. I am not sure what is the best way to do this without a visible performance impact, maybe we can just push them locally in few places where
__call__is special-cased for subtyping/inference (also there may be an additional complication that we may need to "anonimize" generic callables before hashing them, not sure if this is needed).erictraut commentedon Aug 13, 2023
I'm not able to repro a crash with the latest version of mypy (1.5). I suspect it was fixed somewhere along the way.
hauntsaninja commentedon Aug 13, 2023
Fixed in #14178, but I think worth adding Ivan's test case
Add regression test for expand type -> simplified union crash
Add regression test for expand type -> simplified union crash (#15864)