internal server error - dmypy daemon crashed #18396
Labels
Comments
|
Are you sure that's the right file? The traceback says that it crashed visiting an import from: |
|
Yeah, the traceback suggests |
|
Hi. supervised/engines.py does not exist anymore. I deleted it. Maybe I clear mypy cache? |
I'm sure! Also, I'm using the mypy extension, from Matan Gover. That might not be your problem, right? I should tell the extension author. The error I told you happens automatically. I didn't run any mypy command. The extension is running mypy daemon in the background. I tested now in a file called Just replicated the error again now: [62] Error running mypy in /Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks: the mypy daemon crashed. This is probably a bug in mypy itself, see Output panel for details. The daemon will be restarted automatically. Idk where to look honestly |
|
The traceback is different now (and is plausible on the repro you gave), so that's good! I'm not sure why it's happening since I'm not familiar with mypyd :/ |
|
Hi, I wanted to know whether this bug has been fixed. |
|
It is unlikely this bug has been fixed. You can always install mypy via |
|
Just reproduced the error again, more details below: Daemon crashed!
Traceback (most recent call last):
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/dmypy_server.py", line 237, in serve
resp = self.run_command(command, data)
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/dmypy_server.py", line 286, in run_command
ret = method(self, **data)
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/dmypy_server.py", line 354, in cmd_run
return self.check(sources, export_types, is_tty, terminal_width)
~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/dmypy_server.py", line 433, in check
messages = self.fine_grained_increment_follow_imports(
sources, explicit_export_types=export_types
)
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/dmypy_server.py", line 701, in fine_grained_increment_follow_imports
messages = fine_grained_manager.update([], to_delete)
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/server/update.py", line 286, in update
changed_modules = propagate_changes_using_dependencies(
self.manager,
...<5 lines>...
self.processed_targets,
)
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/server/update.py", line 882, in propagate_changes_using_dependencies
triggered |= reprocess_nodes(manager, graph, id, nodes, deps, processed_targets)
~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/server/update.py", line 1011, in reprocess_nodes
semantic_analysis_for_targets(graph[module_id], nodes, graph, saved_attrs)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/semanal_main.py", line 137, in semantic_analysis_for_targets
process_top_levels(graph, [state.id], patches)
~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/semanal_main.py", line 220, in process_top_levels
deferred, incomplete, progress = semantic_analyze_target(
~~~~~~~~~~~~~~~~~~~~~~~^
next_id, next_id, state, state.tree, None, final_iteration, patches
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/semanal_main.py", line 351, in semantic_analyze_target
analyzer.refresh_partial(
~~~~~~~~~~~~~~~~~~~~~~~~^
refresh_node,
^^^^^^^^^^^^^
...<4 lines>...
active_type=active_type,
^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/semanal.py", line 647, in refresh_partial
self.refresh_top_level(node)
~~~~~~~~~~~~~~~~~~~~~~^^^^^^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/semanal.py", line 658, in refresh_top_level
self.accept(d)
~~~~~~~~~~~^^^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/semanal.py", line 7303, in accept
report_internal_error(err, self.errors.file, node.line, self.errors, self.options)
~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/errors.py", line 1289, in report_internal_error
raise err
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/semanal.py", line 7301, in accept
node.accept(self)
~~~~~~~~~~~^^^^^^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/nodes.py", line 1183, in accept
return visitor.visit_class_def(self)
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/semanal.py", line 1788, in visit_class_def
self.analyze_class(defn)
~~~~~~~~~~~~~~~~~~^^^^^^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/semanal.py", line 1929, in analyze_class
bases, tvar_defs, is_protocol = self.clean_up_bases_and_infer_type_variables(
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
defn, bases, context=defn
^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/semanal.py", line 2240, in clean_up_bases_and_infer_type_variables
self.analyze_type_expr(base_expr)
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/semanal.py", line 7355, in analyze_type_expr
expr.accept(self)
~~~~~~~~~~~^^^^^^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/nodes.py", line 1895, in accept
return visitor.visit_member_expr(self)
~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/semanal.py", line 5906, in visit_member_expr
base.accept(self)
~~~~~~~~~~~^^^^^^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/nodes.py", line 1873, in accept
return visitor.visit_name_expr(self)
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/semanal.py", line 5651, in visit_name_expr
n = self.lookup(expr.name, expr)
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/semanal.py", line 6345, in lookup
self.name_not_defined(name, ctx)
~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/semanal.py", line 7176, in name_not_defined
self.fail(message, ctx, code=codes.NAME_DEFINED)
~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/semanal.py", line 7282, in fail
self.errors.report(ctx.line, ctx.column, msg, blocker=blocker, code=code)
~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/errors.py", line 464, in report
self.add_error_info(info)
~~~~~~~~~~~~~~~~~~~^^^^^^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/errors.py", line 530, in add_error_info
self._add_error_info(file, info)
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
File "/Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks/.venv/lib/python3.13/site-packages/mypy/errors.py", line 467, in _add_error_info
assert file not in self.flushed_files
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
[34] Error running mypy in /Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks: the mypy daemon crashed. This is probably a bug in mypy itself, see Output panel for details. The daemon will be restarted automatically. |
|
I have the same exception. It could be induced by ungraceful shutdown of the daemon. |
|
I ran into the same issue and posted my problem to #15486. @hauntsaninja suggested it's actually this bug. I did a bisect and determined that I don't get the crash in 1.13.0 but I do get the crash in 1.14.0 The behavior I see is that from a fresh |
|
Hmm, I couldn't trivially repro on 8774884 with numpy 2.1. I introduced a type error in |
|
I'm getting this more and more on Windows lately with this assertion stack trace: |
|
@hauntsaninja sorry for the delay! I just did a clean clone of my repo and indeed I can't reproduce the error in that clean clone. The kind of type error I'm introducing doesn't seem to matter on my main clone. I'm trying, for example, something like this: Notice the missing annotation for Does mypy keep some state around that survives a |
|
I've managed to repro it on my private repo as well with mypy 1.15. I had to remove an import and run dmypy 2-3 times to get it. |
|
I'm also seeing this problem, I have the same symptom as gerner where it can compile the first couple of times after a restart then crashes. I've tried two kinds of syntax error and both produce the same effect: missing import and non-existent variable. This started immediately after upgrading from 1.9 to 1.15. I've tried clearing my Another engineer I work with (@lukaspiatkowski, you beat me to posting 🙂) was able to reproduce this on their copy of the same code, so I don't think it's tied to any local state on my machine. We're going to try downgrading to 1.13. |
|
Increased priority to high, since this looks like a regression and is impacting multiple users. |
|
I think I managed to bisect to a commit: 976d105 -- but... For repro, I used https://github.com/gerner/stellarpunk/tree/87748840624727e521b7641bd947b17f71ca061d. I could only repro this with Python 3.13.1 built from source on Linux, in a venv, and all requirements from stellarpunk's requirements.txt installed. Missing some dependencies would lead to a no repro. I also looked briefly at the commit. If I undo the changes to mypy/server/update.py (changes to SENSITIVE_INTERNAL_MODULES logic) it seems to no longer crash. Haven't gotten to look deeper, but I think the bisected commit might have only exposed the bug, or made it more obvious. |
|
I'm able to reproduce the behavior both in a venv made by uv, and in a conda environment (same repo). |
|
I am getting the same error. I've had to stop using dmypy as a result |
|
Following the investigation by @svalentin (thanks!), a few more observations:
It's slow as hell, but at least happens consistently (. I wasn't able to narrow the scope further. The following crashed 5/5 during the second run: cd "$(mktemp -d)"
git clone https://github.com/gerner/stellarpunk
cd stellarpunk && git checkout 87748840624727e521b7641bd947b17f71ca061d
uv venv && . .venv/bin/activate && uv pip install 'mypy==1.15.0' 'imageio==2.37.0'
dmypy restart && for i in {1..3}; do dmypy run; done |
|
Hm, I might be onto something - can someone more familiar with dmypy updates take a look at my observations?
With the following patch: diff --git a/mypy/build.py b/mypy/build.py
index 355ba8613..1fb271848 100644
--- a/mypy/build.py
+++ b/mypy/build.py
@@ -99,7 +99,7 @@ from mypy.version import __version__
# mode only that is useful during development. This produces only a subset of
# output compared to --verbose output. We use a global flag to enable this so
# that it's easy to enable this when running tests.
-DEBUG_FINE_GRAINED: Final = False
+DEBUG_FINE_GRAINED: Final = True
# These modules are special and should always come from typeshed.
CORE_BUILTIN_MODULES: Final = {
diff --git a/mypy/dmypy_server.py b/mypy/dmypy_server.py
index d73487efe..cc76dc286 100644
--- a/mypy/dmypy_server.py
+++ b/mypy/dmypy_server.py
@@ -694,6 +694,7 @@ class Server:
if module_id not in graph:
continue
if module_id not in seen:
+ print(f"xxx {module_id} {sorted(seen)!r}", file=sys.stderr)
module_path = graph[module_id].path
assert module_path is not None
to_delete.append((module_id, module_path))I get the following log: Long scrolling!Here's the list from "xxx" unwrapped and sorted: Full listPIL This feels wrong - if we have
Honestly, I'm done for today, I'd appreciate if someone who knows this part better could confirm whether I'm on the right track. |
|
Well, the following (I don't know whether this is a reasonable thing to do or the patch should be at some lower level!) fixes the symptoms. It also fixes the "vanishing error" problem I mentioned earlier, so the dependency omission is indeed the common cause for both of them? @ilevkivskyi sorry to bother you, but it's a p-high issue affecting many users, and you should be familiar with this This change also somehow fixes #17652 (I'm able to reproduce that one consistently on 1.15.0 and it's gone with this patch applied) |
|
FWIW something very wrong happens here. IIUC there were no changes between |
|
That happens on the third and subsequent runs, while the second run is still slow (for me it's like 80s, 20s, <0.5s with non-compiled mypy). With the patch applied, it goes exactly as you say: all runs after the first complete immediately ( So either this is the right thing to do or dependency is missed somewhere else. |
|
Wait, but it is the right thing to do. When we traverse dependencies in Lines 472 to 497 in a4e79ea I'm opening a PR with this change. I don't yet understand how to write a self-contained unit test, but at least understand why my suggestion actually helps. Now some ancestors are unreachable when we only consider explicit dependencies, and so dmypy treats those modules as deleted. Modules are still there, the state becomes inconsistent. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug Report
./src/intellibricks/models/supervised/engines.py: error: INTERNAL ERROR -- Please try using mypy master on GitHub:
https://mypy.readthedocs.io/en/stable/common_issues.html#using-a-development-mypy-build
Please report a bug at https://github.com/python/mypy/issues
version: 1.14.1
Daemon crashed!
Traceback (most recent call last):
File "mypy/dmypy_server.py", line 236, in serve
File "mypy/dmypy_server.py", line 285, in run_command
File "mypy/dmypy_server.py", line 353, in cmd_run
File "mypy/dmypy_server.py", line 432, in check
File "mypy/dmypy_server.py", line 700, in fine_grained_increment_follow_imports
File "mypy/server/update.py", line 285, in update
File "mypy/server/update.py", line 881, in propagate_changes_using_dependencies
File "mypy/server/update.py", line 1010, in reprocess_nodes
File "mypy/semanal_main.py", line 137, in semantic_analysis_for_targets
File "mypy/semanal_main.py", line 220, in process_top_levels
File "mypy/semanal_main.py", line 351, in semantic_analyze_target
File "mypy/semanal.py", line 646, in refresh_partial
File "mypy/semanal.py", line 657, in refresh_top_level
File "mypy/semanal.py", line 7288, in accept
File "mypy/errors.py", line 1288, in report_internal_error
File "mypy/semanal.py", line 7286, in accept
File "mypy/nodes.py", line 471, in accept
File "mypy/semanal.py", line 2958, in visit_import_from
File "mypy/semanal.py", line 3054, in report_missing_module_attribute
File "mypy/semanal.py", line 7267, in fail
File "mypy/errors.py", line 463, in report
File "mypy/errors.py", line 529, in add_error_info
File "mypy/errors.py", line 466, in _add_error_info
AssertionError
[35] Error running mypy in /Users/arthurbrenno/Documents/Dev/Public/ctx/intellibricks: the mypy daemon crashed. This is probably a bug in mypy itself, see Output panel for details. The daemon will be restarted automatically.
To Reproduce
uv python install 3.13.1 uv python pin 3.13.1 uv venv source .venv/bin/activate uv add mypy --dev dmypy startYour Environment
mypy.ini(and other config files):The text was updated successfully, but these errors were encountered: