Spyder crashes after Monitor Scale change #14273

nc011 · 2020-11-20T10:21:44Z

Description

Spyder crashes after closing ("dismiss") the Monitor Scale change detected pop-up on remote machine.

What steps will reproduce the problem?

Specific scenario:

Connect to a Remote Desktop with one monitor scale size.
Open Spyder on that Remote Desktop machine.
Close Remote Desktop connection (keep Spyder open on the remote machine).
Re-connect to the same Remote Desktop with a different monitor scale size (e.g. a different local machine).
Spyder produces Monitor Scale change detected pop-up. Click dismiss.
Spyder will crash/close with no error thrown.

Note: monitor scale change pop up seems to work normally when I move Spyder (in the RD window) between monitors on the local machine.

Pure speculation: could it be that there are three monitor scale changes going on (local machine #1 > remote machine (when RD connection from LM1 is closed) > local machine #2) which is what's causing the issue?

Versions

Spyder version: 4.1.5
Python version: 3.8.3
Qt version: 5.9.7
PyQt5 version: 5.9.2
Operating System: Windows 10

Dependencies


# Mandatory:
atomicwrites >=1.2.0           :  1.4.0 (OK)
chardet >=2.0.0                :  3.0.4 (OK)
cloudpickle >=0.5.0            :  1.6.0 (OK)
diff_match_patch >=20181111    :  20200713 (OK)
intervaltree                   :  None (OK)
IPython >=4.0                  :  7.18.1 (OK)
jedi =0.17.1                   :  0.17.1 (OK)
nbconvert >=4.0                :  5.6.1 (OK)
numpydoc >=0.6.0               :  1.1.0 (OK)
paramiko >=2.4.0               :  2.7.2 (OK)
parso =0.7.0                   :  0.7.0 (OK)
pexpect >=4.4.0                :  4.8.0 (OK)
pickleshare >=0.4              :  0.7.5 (OK)
psutil >=5.3                   :  5.7.2 (OK)
pygments >=2.0                 :  2.6.1 (OK)
pylint >=1.0                   :  2.6.0 (OK)
pyls >=0.34.0;<1.0.0           :  0.34.1 (OK)
qdarkstyle >=2.8               :  2.8.1 (OK)
qtawesome >=0.5.7              :  0.7.2 (OK)
qtconsole >=4.6.0              :  4.7.6 (OK)
qtpy >=1.5.0                   :  1.9.0 (OK)
rtree >=0.8.3                  :  0.9.4 (OK)
sphinx >=0.6.6                 :  3.2.1 (OK)
spyder_kernels >=1.9.4;<1.10.0 :  1.9.4 (OK)
watchdog                       :  None (OK)
zmq >=17                       :  19.0.1 (OK)

# Optional:
cython >=0.21                  :  0.29.21 (OK)
matplotlib >=2.0.0             :  3.3.1 (OK)
numpy >=1.7                    :  1.19.1 (OK)
pandas >=0.13.1                :  1.1.1 (OK)
scipy >=0.17.0                 :  1.5.0 (OK)
sympy >=0.7.3                  :  1.6.2 (OK)

The text was updated successfully, but these errors were encountered:

nc011 · 2020-11-20T10:46:49Z

I believe this is related, rather than a seperate issue - so am following up with this.

Sometimes I will get the scale change pop up appear twice. After dismissing both, Spyder closes/crashes.

(Edits to image for privacy/security)

juanis2112 · 2020-11-21T00:11:22Z

Hi @Caseyb87. Thanks for reporting this! @dalthviz can you please try to reproduce this on Windows?

dalthviz · 2020-11-21T01:45:07Z

@Caseyb87 could you run Spyder from cmd in you remote machine and check if any traceback appears in the console? And thanks for the info :)

Also, if I manage to get a way to test this I will let you know @juanis2112 (currently I don't have access to a remote windows machine to check with a remote desktop connection). @andfoy you have access to remote windows machines to check this?

nc011 · 2020-11-24T09:02:27Z

@Caseyb87 could you run Spyder from cmd in you remote machine and check if any traceback appears in the console? And thanks for the info :)

No - nothing appears in cmd (I ran through Anaconda prompt). If there are any other debugging steps I can take or log files that might contain anything useful do let me know.

dalthviz · 2020-11-24T14:14:18Z

@Caseyb87 maybe running spyder --debug-info verbose from the Anaconda Prompt could show something.

Any new info is greatly appreciated :)

nc011 · 2020-11-24T16:31:28Z

@Caseyb87 maybe running spyder --debug-info verbose from the Anaconda Prompt could show something.

Any new info is greatly appreciated :)

Looks like something got recorded. This was triggered after clicking "dismiss" on the prompt (the previous line was just an autosave). Spyder then crash/closed.

2020-11-24 16:27:12,753 [DEBUG] [urllib3.connectionpool] -> http://127.0.0.1:46624 "GET /clientapi/status?filename=removed for privacy HTTP/1.1" 200 121
QPaintDevice::metrics: Device has no metric information
QPaintDevice::metrics: Device has no metric information
QPaintDevice::metrics: Device has no metric information
QPaintDevice::metrics: Device has no metric information
Traceback (most recent call last):
File "C:\Users\ username \Anaconda3\lib\site-packages\spyder\app\mainwindow.py", line 1414, in handle_new_screen
self.screen.logicalDotsPerInchChanged.connect(
AttributeError: 'NoneType' object has no attribute 'logicalDotsPerInchChanged'
QPaintDevice::metrics: Device has no metric information
QPaintDevice::metrics: Device has no metric information
QPaintDevice::metrics: Device has no metric information

Hopefully that's helpful!

dalthviz · 2020-11-24T16:38:21Z

Thanks @Caseyb87 !

byersiiasa · 2020-12-12T00:20:42Z

I have this problem too - it is real. Thanks for trying to resolve.

nc011 · 2020-12-15T10:08:12Z

Confirmed still present in 4.2.0 (unsurprisingly) - also enabling the "Enable auto high res DPI" setting does not prevent the crash.

arnaud-nt2i · 2021-01-09T10:12:41Z

HI! @ccordoba12 why removing it from milestone ? It will be resolved in 4.2.2 ?
I am having the same issue on two W10 devices (with remote desktop access).
VERY annoying bug! because a day-long work has disappeared ...

nc011 · 2021-01-09T17:16:37Z

HI! @ccordoba12 why removing it from milestone ? It will be resolved in 4.2.2 ?
I am having the same issue on two W10 devices (with remote desktop access).
VERY annoying bug! because a day-long work has disappeared ...

I guess because they don't plan to fix it in the upcoming release - which is a shame as this is a major bug, but probably only for quite a limited set of users.

I think preventing the crash shouldn't be too hard, just check that self.screen is not None I guess. Or just wrap this whole block in a try and catch. Fixing why self.screen is NoneType may be harder but may not be necessary.

dalthviz · 2021-01-09T21:09:44Z

Hi @arnaud-nt2i sorry to hear that :/ and yes as @Caseyb87 said, basically we will not be working on this for the next release. However if someone else wants to work on it (for example if you guys @Caseyb87 or @arnaud-nt2i want to try to fix the issue) we could review the work and add it to the next release! (if finished before the next release of course).

So, let us know if you guys want to try to implement the fix! We will more than happy to guide/help you and review the work :D

ccordoba12 · 2021-01-09T22:33:03Z

@Caseyb87, I thought this was harder to solve, but you're right, we could catch the error and pass. So we'll try to solve it for 4.2.2

@dalthviz, do you have a way to connect remotely to another Windows machine to test this?

dalthviz · 2021-01-09T22:42:08Z

@dalthviz, do you have a way to connect remotely to another Windows machine to test this?

Nop that's one of the main reasons why I was unable to reproduce this and find the root cause of the issue (I was unable to reproduce this by using just a local Spyder instance)

ccordoba12 · 2021-01-10T01:10:19Z

Ok, I think we can ask @CAM-Gerlach to give us a hand with that. @CAM-Gerlach, are you able to connect to a Windows machine using Remote Desktop?

CAM-Gerlach · 2021-01-10T14:23:56Z

I can RDP into machines with Spyder installed, but the remote machines are configured by the admin to log out the connected account if I terminate the RDP connection. Therefore, I was not able to reproduce the specific problem, since it seems to require reconnecting to the same logged in session after terminating the connection previously.

You'll need someone with access to a Windows machine over RDP that does not have the setting configured to log the user out automatically when disconnecting RDP so they can re-connect to the same session, or else that has control/admin on a RDP-acessable machine where they can set this setting. Alternatively, the user could try to find a way to reproduce the issue without re-connecting to the same active session (e.g. while still connected over RDP, like forcing a monitor scale change locally), but this may simply not be possible due to the nature of the problem.

This is a pretty niche case; I'm sorry I don't have a better solution.

bilderbuchi · 2021-01-13T18:29:24Z

I think that is what I did by putting

if screen is None:
    return

in the beginning of the method. Unfortunately, the crash/close when clicking the menu then occurs - do you think those two are unrelated?

dalthviz · 2021-01-13T18:53:31Z

Um that's strange, and are you able to capture any kind of traceback in the console/terminal/cmd after Spyder crashes/closes when running with --debug-info verbose?

My guess is that somehow GUI objects are getting destroyed when disconnecting and reconnecting through RDP but not totally sure (maybe such destruction is related with the messages about QPaintDevice::metrics: Device has no metric information)

bilderbuchi · 2021-01-13T19:30:42Z

python .\bootstrap.py (for running master) does not recognize --debug-info verbose, only --debug.
No traceback, hence my suspicion that any thrown exception gets swallowed by Qt internally.
When triggering the bug with the early return in place, pressing "Dismiss" (no crash) and then clicking the menu, the last couple of pages from the --debug log:

2021-01-13 20:23:29,863 [DEBUG] [spyder.plugins.editor.utils.autosave] -> Autosave triggered
2021-01-13 20:23:32,704 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:32,704 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:33,694 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:33,694 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:34,696 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:34,696 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:34,696 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:34,696 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:35,706 [INFO] [spyder.plugins.completion.languageserver.plugin] -> Automatic restart attempt 5 for python...
2021-01-13 20:23:35,706 [DEBUG] [spyder.plugins.editor.widgets.codeeditor] -> Stopping completion services for C:\Users\buchner\.spyder-py3-dev\temp.py
2021-01-13 20:23:35,706 [INFO] [spyder.plugins.completion.languageserver.plugin] -> Stopping LSP client for python...
2021-01-13 20:23:35,706 [INFO] [spyder.plugins.completion.languageserver.client] -> Stopping python client...
2021-01-13 20:23:35,706 [INFO] [spyder.plugins.completion.languageserver.plugin] -> Starting LSP client for python...
2021-01-13 20:23:35,716 [INFO] [spyder.plugins.completion.languageserver.client] -> Starting server: C:\Continuum\anaconda3\envs\spyder-14273\python.exe -m pyls --host 127.0.0.1 --port 2087 --tcp --check-parent-process --log-file C:\Users\buchner\.spyder-py3-dev\lsp_logs\server_python_17508.log -vv
2021-01-13 20:23:35,726 [INFO] [spyder.plugins.completion.languageserver.client] -> Starting transport for python: C:\Continuum\anaconda3\envs\spyder-14273\python.exe -u \\<snip>\Python\spyder\spyder\plugins\completion\languageserver\transport\main.py --folder C:\Users\buchner\.spyder-py3-dev\lsp_paths\root_path --transport-debug 3 --server-host 127.0.0.1 --server-port 2087  --zmq-in-port 59398 --zmq-out-port 59399 --external-server
2021-01-13 20:23:35,736 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP python client started!
2021-01-13 20:23:35,736 [INFO] [spyder.plugins.completion.languageserver.plugin] -> Restart failed!
2021-01-13 20:23:35,736 [INFO] [spyder.plugins.completion.languageserver.client] -> Stopping python client...
2021-01-13 20:23:36,696 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:36,696 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:37,688 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:37,688 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:37,688 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:37,688 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:38,709 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:38,709 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:39,689 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:39,689 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:40,700 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:40,700 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:40,700 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:40,700 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:41,706 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:41,706 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:42,696 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:42,696 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:43,696 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:43,696 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:43,696 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:43,696 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:45,498 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:45,499 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:45,688 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:45,688 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:46,699 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:46,699 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:46,700 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:46,700 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:47,709 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:47,709 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
QPaintDevice::metrics: Device has no metric information
QPaintDevice::metrics: Device has no metric information
QPaintDevice::metrics: Device has no metric information
QPaintDevice::metrics: Device has no metric information
QPaintDevice::metrics: Device has no metric information
QPaintDevice::metrics: Device has no metric information
QPaintDevice::metrics: Device has no metric information
QPaintDevice::metrics: Device has no metric information
QPaintDevice::metrics: Device has no metric information
2021-01-13 20:23:48,696 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:48,696 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:49,692 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:49,692 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
2021-01-13 20:23:49,692 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:49,692 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!
QPaintDevice::metrics: Device has no metric information
QPaintDevice::metrics: Device has no metric information
QPaintDevice::metrics: Device has no metric information
QPaintDevice::metrics: Device has no metric information
2021-01-13 20:23:49,965 [DEBUG] [urllib3.connectionpool] -> Starting new HTTP connection (3): 127.0.0.1:46624
QPaintDevice::metrics: Device has no metric information
QPaintDevice::metrics: Device has no metric information
QPaintDevice::metrics: Device has no metric information
QPaintDevice::metrics: Device has no metric information
2021-01-13 20:23:50,710 [DEBUG] [spyder.plugins.completion.languageserver.client] -> Transport layer for python is down!!
2021-01-13 20:23:50,710 [DEBUG] [spyder.plugins.completion.languageserver.client] -> LSP server for python is down!!

You'll notice that the QPaintDevice messages have no timestamp/loglevel decoration, and that there is no traceback at the end, just the process ending (seemingly normally), the next line is just the shell prompt. I'm not sure if the LSP stuff is related, I think on some executions/runs the log is not spammed like that.

nc011 · 2021-01-13T19:44:10Z

What happens if you wrap the section

spyder/spyder/app/mainwindow.py

Lines 1535 to 1541 in a3a35fd

    
           if not sys.platform == 'darwin': 
        
               window = self.window().windowHandle() 
        
               window.screenChanged.connect(self.handle_new_screen) 
        
               self.screen = self.window().windowHandle().screen() 
        
               self.current_dpi = self.screen.logicalDotsPerInch() 
        
               self.screen.logicalDotsPerInchChanged.connect( 
        
                   self.show_dpi_change_message)

in a try?

I was just wondering if the screen is None is causing problems elsewhere, not just in handle_new_screen().

If the error is caught there then Spyder should (maybe?) just act like the screen never changed?

dalthviz · 2021-01-13T19:56:42Z

I was thinking something similar too @Caseyb87.

However, searching a little bit I found that maybe this could be Qt related:

https://bugreports.qt.io/browse/QTBUG-84161?jql=text%20~%20%22Device%20has%20no%20metric%20information%22 (although is not reported for Windows)

Also regarding the messages about the LSP seems like that is also failing (the LSP crashes and is not being able to restart)

CAM-Gerlach · 2021-01-13T23:06:13Z

python .\bootstrap.py (for running master) does not recognize --debug-info verbose, only --debug.

Sorry it was unclear—you need to pass that option through to Spyder, not the bootstrap.py script, via python bootstrap.py -- --debug-info verbose. The bootstrap.py script also has a debug option, which IIRC its equivalent, and its a relic from a time when Spyder itself didn't have that option and the semantics were different from what they are now, just an on-off switch instead of multiple levels.

python bootstrap.py -- --debug-info verbose

Unfortunately, the crash/close when clicking the menu then occurs - do you think those two are unrelated?

@dalthviz 's Qt knowledge vastly exceeds mine, but FWIW, the evidence available is consistent with some problem caused by the user session's screen being disconnected for some time, and then another reconnected; as this is a pretty niche case on Windows (compared to *nix, with X11 forwarding and lots of screenless boxes) its possible that simply no one has reported it in this case. I'm not sure what exactly we can do about it at the Spyder level, as it seems its something at the Qt level given we're not seeing an exception traceback in Spyder and its instead just crashing to desktop, and the core GUI of the menu bar etc. is handled by Qt. I only see calls to the screen object (self.screen in the code relating to checking for a DPI change, which shouldn't be triggered in that scenario once its try-excepted.

ccordoba12 · 2021-01-14T00:42:09Z

What happens if you wrap the section in a try?

@bilderbuchi, instead of doing that, please replace

if not sys.platform == 'darwin':

by

if False:

That would avoid executing that if block at all. I don't think it'll work, but at least we'll be sure if it has some influence on the crash.

ccordoba12 · 2021-01-14T00:45:04Z

https://bugreports.qt.io/browse/QTBUG-84161?jql=text%20~%20%22Device%20has%20no%20metric%20information%22

I also found this bug while searching for possible solutions. So this problem looks like a bug in Qt, and in that case we won't be able to do anything about it.

Basically, it seems the screen is removed by Windows after you logout from Remote desktop and recreated again after you start a new session.

nc011 · 2021-01-14T11:29:50Z

https://bugreports.qt.io/browse/QTBUG-84161?jql=text%20~%20%22Device%20has%20no%20metric%20information%22

I also found this bug while searching for possible solutions. So this problem looks like a bug in Qt, and in that case we won't be able to do anything about it.

I'll be interested to see if avoiding that if block works. But I guess what you're saying is that even if Spyder is changed to "handle" screen is None, Qt (and thus also Spyder) may still crash?

This should, of course, be reported to Qt. Probably best by one of the Spyder developers?

Basically, it seems the screen is removed by Windows after you logout from Remote desktop and recreated again after you start a new session.

But only if you start a new session in from a new local machine. That's the weird part. It all works fine if you start the new session from the same local machine (or at least same display).

bilderbuchi · 2021-01-17T10:06:23Z

if False:

with this change and the early return in place, I get neither the screen change dialog, nor can I trigger any crashes anymore.

It all works fine if you start the new session from the same local machine (or at least same display).

The repro procedure I have been using is using a laptop (1080p display) with an external monitor attached (1680x1050) to connect to a remote PC (1080p display). By switching on either only the laptop screen or only the external monitor when connecting to the remote PC, I can force a change in resolution and trigger the bug.

nc011 · 2021-01-17T10:47:37Z

if False:

with this change and the early return in place, I get neither the screen change dialog, nor can I trigger any crashes anymore.

Fantastic! So Spyder can handle this (by just ignoring it), even if it is a bug with Qt.

It all works fine if you start the new session from the same local machine (or at least same display).

The repro procedure I have been using is using a laptop (1080p display) with an external monitor attached (1680x1050) to connect to a remote PC (1080p display). By switching on either only the laptop screen or only the external monitor when connecting to the remote PC, I can force a change in resolution and trigger the bug.

Ah OK - that makes sense, it's the display (not the device) that is important.

nc011 · 2021-01-18T11:58:38Z

I've managed to get a dev version of Spyder set up myself too. I can confirm @bilderbuchi 's observations in that skipping that block entirely results in no crashing.

Additionally, if lines 1556-1558 are commented out:

spyder/spyder/app/mainwindow.py

Lines 1556 to 1558 in 72e9952

    
           self.current_dpi = self.screen.logicalDotsPerInch() 
        
           self.screen.logicalDotsPerInchChanged.connect( 
        
               self.show_dpi_change_message)

then Spyder does not crash but will throw the following error:

if self.current_dpi != screen.logicalDotsPerInch():
AttributeError: 'MainWindow' object has no attribute 'current_dpi'

I tried to add some condition code to prevent those lines being executed but couldn't get it to work. Guess I'm checking the wrong thing. For example:

if not sys.platform == 'darwin':
            window = self.window().windowHandle()
            if window.screen() is not None:
                        window.screenChanged.connect(self.handle_new_screen)
                        self.screen = self.window().windowHandle().screen()
                        self.current_dpi = self.screen.logicalDotsPerInch()
                        self.screen.logicalDotsPerInchChanged.connect(
                            self.show_dpi_change_message)

did not work. Spyder still showed the dpi change messages and then crashed after clicking dismiss.

nc011 · 2021-01-18T12:01:58Z

Additionally, I think I figured out why the dpi change message is being shown twice.

spyder/spyder/app/mainwindow.py

Line 1554 in 72e9952

window.screenChanged.connect(self.handle_new_screen)

calls handle_new_screen which can then call show_dpi_change_message

spyder/spyder/app/mainwindow.py

Lines 1575 to 1576 in 72e9952

    
           if self.current_dpi != screen.logicalDotsPerInch(): 
        
               self.show_dpi_change_message(screen.logicalDotsPerInch())

but

spyder/spyder/app/mainwindow.py

Lines 1557 to 1558 in 72e9952

    
           self.screen.logicalDotsPerInchChanged.connect( 
        
               self.show_dpi_change_message)

also calls show_dpi_change_message.

Perhaps this behaviour is OK in normal situations but I guess due to this particular issue, we end up with the show_dpi_change_message being shown twice.

dalthviz · 2021-01-18T18:25:44Z

Thanks @bilderbuchi and @Caseyb87 for the info regarding this! Seems like now we have more clues about how to prevent the crash to happen :) Maybe the condition to check needs to be regarding if we are currently running in a RDP session (although I'm unsure how we can achieve such validation :/)

tsprhdm · 2021-02-02T09:26:38Z

I can reproduce something similar with Version 4.1.5 AND 4.2.0 on Windows 10 20H2Build 19042.746.

Sypder is installed through Anaconda.

I opened Spyder on my secondary screen, through thunderbolt dock.

Unplugged the laptop. Spyder opens on a non-existing screen. Some dialogs are shown (the update to 4.2.0) dialogue pops up on the only aptop screen, but as soon as the main window opens (animation zooming out of task bar sometimes shows the window moving to the screen on the left), spyder crashes and disappears from the task bar.

No processes to be seen in task explorer.

So, no remote desktop, only physical screens, but similar issues.

Spyder --debug-info verbose --report-segfault

It crashes right after the urrlib3 call (left out lots of lines!)

...
...
2021-02-02 10:37:09,809 [DEBUG] [spyder.plugins.completion.fallback.actor] -> Perform request textDocument/documentSymbol with id 2
2021-02-02 10:37:09,835 [DEBUG] [spyder.plugins.completion.plugin] -> Completion plugin: Request 1 Got response from lsp
2021-02-02 10:37:09,836 [DEBUG] [spyder.plugins.completion.plugin] -> Completion plugin: Request 1 removed
2021-02-02 10:37:09,837 [DEBUG] [spyder.plugins.completion.plugin] -> Gather responses for textDocument/foldingRange
2021-02-02 10:37:09,969 [DEBUG] [spyder.plugins.completion.plugin] -> Completion plugin: Request 2 Got response from lsp
2021-02-02 10:37:09,969 [DEBUG] [spyder.plugins.completion.plugin] -> Completion plugin: Request 2 removed
2021-02-02 10:37:09,969 [DEBUG] [spyder.plugins.completion.plugin] -> Gather responses for textDocument/documentSymbol
2021-02-02 10:37:11,315 [DEBUG] [urllib3.connectionpool] -> Starting new HTTP connection (3): 127.0.0.1:46624
2021-02-02 10:37:13,332 [DEBUG] [spyder.plugins.completion.plugin] -> Completion plugin: Request 0 Got response from kite
2021-02-02 10:37:13,337 [DEBUG] [urllib3.connectionpool] -> Starting new HTTP connection (4): 127.0.0.1:46624

No segfault-reporter popping up!

tsprhdm · 2021-02-02T09:57:45Z

Just downgraded to 3.3.6.

Windows stayed open, i could move it to the laptop screen. Closed Sypder 3.3.6 gracefully.

updated to 4.1.5.

segfault reporter pops up. then crash, spyder goes away

Tried --reset and --defaults, but 4.1.5 still always crashes some seconds after showing up on the main screen.

ccordoba12 · 2021-02-10T02:37:36Z

Hey everyone, @dalthviz managed to fix this problem in PR #14696. We'd really appreciate your help to extra test it and be sure that we correctly fixed this nasty crash (@dalthviz already tested it). For that you need to install git and follow our Contributing guide.

Also, we don't have a way to test this in thunderbolt dock. So we'd appreciate your help with that too.

nc011 · 2021-02-10T11:38:48Z

I tried to test this out but couldn't get it working - sorry (new to Git). I got Spyder running on the 4.x branch but it didn't have this fix in it. I tried to follow the contributing guide but it wasn't clear to me how to get Spyder to run with the new fix in. If anyone can help me figure that out, I'm happy to test.

CAM-Gerlach · 2021-02-10T16:03:30Z

You need to check out the PR branch before running Spyder; there are aliases to do that or a manual method involving several steps, but the easiest way is to just download and use hub (e.g. with conda install -c conda-forge hub, or with choco, snoop or as a standalone executable), a git wrapper from Github. Once you install it, you just run hub pr checkout 14696 to check out the above PR #14696 .

nc011 · 2021-02-10T16:37:34Z

You need to check out the PR branch before running Spyder; there are aliases to do that or a manual method involving several steps, but the easiest way is to just download and use hub (e.g. with conda install -c conda-forge hub, or with choco, snoop or as a standalone executable), a git wrapper from Github. Once you install it, you just run hub pr checkout 14696 to check out the above PR #14696 .

Thank you. I tried as you suggested but got a "Not Found" error - must have done something wrong there. In the end, I just copied/pasted new mainwindow.py file into the installation directory and it worked!

I was able to connect/disconnect/reconnect from the remote machine with different local machines and Spyder did not crash. Got the warning (only once), clicked dismiss and was able to continue as expected.

ccordoba12 · 2021-02-10T16:57:13Z

Great! Thanks for the confirmation @Caseyb87! I'm going to merge PR #14696 then.

Hopefully that also fixes the issue with two screens while using a thunderbolt dock. If not, @tsprhdm please open a new issue about it.

bilderbuchi · 2021-02-10T19:34:12Z

Thanks for checking, I did not get the opportunity to quickly test this time around! And also thanks for the fix, of course! 👍

sienamo · 2022-08-25T18:12:28Z

You need to check out the PR branch before running Spyder; there are aliases to do that or a manual method involving several steps, but the easiest way is to just download and use hub (e.g. with conda install -c conda-forge hub, or with choco, snoop or as a standalone executable), a git wrapper from Github. Once you install it, you just run hub pr checkout 14696 to check out the above PR #14696 .

Thank you. I tried as you suggested but got a "Not Found" error - must have done something wrong there. In the end, I just copied/pasted new mainwindow.py file into the installation directory and it worked!

I was able to connect/disconnect/reconnect from the remote machine with different local machines and Spyder did not crash. Got the warning (only once), clicked dismiss and was able to continue as expected.

Hello,
I've had this issue since 2020 and it's been really bothering me for 3 years.
Can you please give me the mainwindow.py file? so that I can copy/paste new mainwindow.py into my installation directory too?

Thanks

dalthviz · 2022-08-25T18:17:11Z

Hi @sienamo , what version of Spyder are you using? Please update to the latest release, Spyder 5.3.2 and check if that helps.

Also, just in case, the related changes to the mainwindow.py file are: https://github.com/spyder-ide/spyder/pull/14696/files and https://github.com/dalthviz/spyder/blob/7802acafaf0faf15031f951b86db5ae3d9658d64/spyder/app/mainwindow.py

sienamo · 2022-08-25T19:00:33Z

Hi @sienamo , what version of Spyder are you using? Please update to the latest release, Spyder 5.3.2 and check if that helps.

Also, just in case, the related changes to the mainwindow.py file are: https://github.com/spyder-ide/spyder/pull/14696/files and https://github.com/dalthviz/spyder/blob/7802acafaf0faf15031f951b86db5ae3d9658d64/spyder/app/mainwindow.py

I am using spyder 5.2.2. I copied and pasted the new mainwindow.py into my installation route. The problem was fixed!
I cannot believe it!!!!Thanks much!!!!

dalthviz · 2022-08-25T19:10:32Z

@sienamo glad to hear the is working for you however, since you are using Spyder 5.2.2, probably copy-pasting the mainwindow.py file linked could introduce new errors to your installation since the file comes from Spyder 4.2.2 and a lot of changes were done for Spyder 5. I would suggest you to install the latest version Spyder (5.3.2).

Not sure about your setup (OS, way you installed Spyder, etc), but if you are using the anaconda distribution, try to create a new environment using only the conda-forge channel. For that, you can run from an Anaconda prompt (Windows) or terminal (MacOS or Linux) the following:

conda create -n spyder-cf -c conda-forge spyder
conda activate spyder-cf
spyder

Then please check if with that new Spyder installation you still got the monitor scale change issue. If the issue persist please open a new issue.

sienamo · 2022-08-26T00:51:08Z

I run your command in anaconda prompt. my spyder version is still 5.2.2.

CAM-Gerlach · 2022-08-26T02:38:44Z

Then either something weird is going on with conda's dependency resolution, or the Spyder you are checking the version on is not the one you installed. To ensure you get the latest version, replace the first line with

conda create -n spyder-cf -c conda-forge spyder=5.3.2

juanis2112 self-assigned this Nov 21, 2020

juanis2112 added the status:Awaiting Followup label Nov 21, 2020

dalthviz added component:Main Window type:Bug and removed status:Awaiting Followup labels Nov 24, 2020

dalthviz added this to the not sorted milestone Nov 24, 2020

ccordoba12 modified the milestones: not sorted, v4.2.2 Nov 24, 2020

ccordoba12 assigned dalthviz and unassigned juanis2112 Nov 24, 2020

ccordoba12 removed this from the v4.2.2 milestone Jan 6, 2021

dalthviz closed this as completed Jan 9, 2021

dalthviz reopened this Jan 9, 2021

ccordoba12 added this to the v4.2.2 milestone Jan 9, 2021

dalthviz mentioned this issue Feb 4, 2021

PR: Improve DPI change detection #14696

Merged

3 tasks

ccordoba12 closed this as completed in aeb5e2f Feb 10, 2021

Spyder crashes after Monitor Scale change #14273

Spyder crashes after Monitor Scale change #14273

Comments

nc011 commented Nov 20, 2020 • edited Loading

Description

What steps will reproduce the problem?

Versions

Dependencies

nc011 commented Nov 20, 2020

juanis2112 commented Nov 21, 2020

dalthviz commented Nov 21, 2020

nc011 commented Nov 24, 2020

dalthviz commented Nov 24, 2020

nc011 commented Nov 24, 2020 • edited Loading

dalthviz commented Nov 24, 2020

byersiiasa commented Dec 12, 2020

nc011 commented Dec 15, 2020

arnaud-nt2i commented Jan 9, 2021

nc011 commented Jan 9, 2021 • edited Loading

dalthviz commented Jan 9, 2021

ccordoba12 commented Jan 9, 2021 • edited Loading

dalthviz commented Jan 9, 2021 • edited Loading

ccordoba12 commented Jan 10, 2021

CAM-Gerlach commented Jan 10, 2021

bilderbuchi commented Jan 13, 2021

dalthviz commented Jan 13, 2021

bilderbuchi commented Jan 13, 2021 • edited Loading

nc011 commented Jan 13, 2021 • edited Loading

dalthviz commented Jan 13, 2021

CAM-Gerlach commented Jan 13, 2021

ccordoba12 commented Jan 14, 2021

ccordoba12 commented Jan 14, 2021

nc011 commented Jan 14, 2021

bilderbuchi commented Jan 17, 2021 • edited Loading

nc011 commented Jan 17, 2021 • edited Loading

nc011 commented Jan 18, 2021

nc011 commented Jan 18, 2021 • edited Loading

dalthviz commented Jan 18, 2021

tsprhdm commented Feb 2, 2021 • edited Loading

tsprhdm commented Feb 2, 2021 • edited Loading

ccordoba12 commented Feb 10, 2021

nc011 commented Feb 10, 2021

CAM-Gerlach commented Feb 10, 2021

nc011 commented Feb 10, 2021

ccordoba12 commented Feb 10, 2021 • edited Loading

bilderbuchi commented Feb 10, 2021

sienamo commented Aug 25, 2022

dalthviz commented Aug 25, 2022

sienamo commented Aug 25, 2022

dalthviz commented Aug 25, 2022

sienamo commented Aug 26, 2022

CAM-Gerlach commented Aug 26, 2022

nc011 commented Nov 20, 2020 •

edited

Loading

nc011 commented Nov 24, 2020 •

edited

Loading

nc011 commented Jan 9, 2021 •

edited

Loading

ccordoba12 commented Jan 9, 2021 •

edited

Loading

dalthviz commented Jan 9, 2021 •

edited

Loading

bilderbuchi commented Jan 13, 2021 •

edited

Loading

nc011 commented Jan 13, 2021 •

edited

Loading

bilderbuchi commented Jan 17, 2021 •

edited

Loading

nc011 commented Jan 17, 2021 •

edited

Loading

nc011 commented Jan 18, 2021 •

edited

Loading

tsprhdm commented Feb 2, 2021 •

edited

Loading

tsprhdm commented Feb 2, 2021 •

edited

Loading

ccordoba12 commented Feb 10, 2021 •

edited

Loading