Home › Forums › Help and Support › Verification crashes DisplayCAL with BadMatch error
- This topic has 2 replies, 1 voice, and was last updated 4 years, 1 month ago by Austin Butler.
-
AuthorPosts
-
2020-02-08 at 1:21 #22719
If I go to the verification tab, then click “Measurement report…” DisplayCAL’s main window crashes or closes, then the “Measurement area” screen shows up (and is the only DisplayCAL process running), then when I click “Start measurement” that window just closes and no DisplayCAL process is running. No file is saved.
I did successfully calibrate and create a profile earlier, which I am using. I’m on Arch Linux, using the package from the repos (v3.8.9.3).
Any ideas on determining the problem?
> $ displaycal XDG: [Errno 2] No translation file found for domain: xdg-user-dirs displaycal 3.8.9.3 2019-12-14T12:16:22.165507Z x86_64 Python 2.7.17 (default, Oct 22 2019, 09:14:09) [GCC 9.2.0] ImportError: No module named faulthandler /usr/lib64/python2.7/site-packages/wx-3.0-gtk3/wx/_core.py:16629: UserWarning: wxPython/wxWidgets release number mismatch wxPython 3.0.2.0 gtk3 (classic) Encoding: UTF-8 File system encoding: UTF-8 Lockfile /home/austin/.config/DisplayCAL/DisplayCAL.lock Existing client using port 36975 Connecting to 36975... Connection to 127.0.0.1:36975 failed: [Errno 111] Connection refused Starting up... SDL2: libSDL2-2.0.so.0 SDL: libSDL-1.2.so.0 Audio module: wx 3.0.2.0 Enumerating display devices and communication ports... /usr/bin ArgyllCMS 2.1.2 Argyll has virtual display support ...ok. Checking video card gamma table access for display 1... Dispwin: Warning - new_dispwin: Expected VideoLUT depth 8 doesn't match actual 10 VideoLUT has 1024 entries, interpolating to 256 Dispwin: Warning - new_dispwin: Expected VideoLUT depth 8 doesn't match actual 10 Dispwin: Warning - new_dispwin: Expected VideoLUT depth 8 doesn't match actual 10 Verify: 'test.cal' IS loaded (discrepancy 0.0%) Dispwin: Warning - new_dispwin: Expected VideoLUT depth 8 doesn't match actual 10 ...ok. Initializing GUI... ...ok. Ready. Setting up scripting host at 127.0.0.1:15411 Check for application update... DisplayCAL is up-to-date. ArgyllCMS is up-to-date. 16:07:34: Debug: window wxComboBox(0x560d02f7b800, ) lost focus even though it didn't have it 16:07:34: Debug: window wxComboBox(0x560d02f7b800, ) lost focus even though it didn't have it 16:07:34: Debug: window wxComboBox(0x560d02f7b800, ) lost focus even though it didn't have it 16:07:34: Debug: window wxComboBox(0x560d02f7b800, ) lost focus even though it didn't have it 16:07:34: Debug: window wxComboBox(0x560d02f7b800, ) lost focus even though it didn't have it 16:07:34: Debug: window wxComboBox(0x560d02f7b800, ) lost focus even though it didn't have it 16:07:34: Debug: window wxComboBox(0x560d02f7b800, ) lost focus even though it didn't have it 16:07:34: Debug: window wxComboBox(0x560d02f7b800, ) lost focus even though it didn't have it Added 3 white patch(es) X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 42 (X_SetInputFocus) Serial number of failed request: 64306 Current serial number in output stream: 64306
2020-02-10 at 6:20 #22803Amusingly, when I try to use the trace module to see what’s going on… it doesn’t crash. This makes me wonder if it’s some sort of a timing issue. With trace running it of course slows down the application. So maybe DisplayCAL is trying to do something with a window that’s already gone or something of that sort?
To test my “it works if the computer is slower” theory, I used
cpulimit
to limit the DisplayCAL process, and yep as expected now I can generate a report. If I limit it to 10% the crash still occurs, but at 5% it doesn’t crash.cpulimit -p $(pgrep displaycal) -l 5
2020-02-10 at 6:31 #22806Opened a bug given the findings above: https://hub.displaycal.net/issue/22804/
-
AuthorPosts