Created attachment 103501 [details] log1 I am working on a file for a couple of minutes, and Krita keeps crashing. Sometimes a tweak the settings of a brush, other times not. I had the same issue a couple of days ago with another file and was also using predefined brush presets. I copied the contents to a new file, switched to custom made brushes and that seemed to solve the problem. This time I tried all of the above, plus erasing the kritarc but the problem persists. I have attached several logs.
Created attachment 103502 [details] log2
Created attachment 103503 [details] log3
Created attachment 103504 [details] log4
Created attachment 103505 [details] log5
Created attachment 103510 [details] log from krita 3.1.88
Created attachment 103511 [details] log2 from krita 3.1.88
Created attachment 103512 [details] log3 from krita 3.1.88
Krita 3.1.88 has the same issue.. Logs attached above. One thing I should mention is that I normally have a Wacom Intuos 3 and a Cintiq plugged at the same time. But after I pluggig the intuos off and restarting the issue persisted. Last update on my Windows 10 was Cumulative Update for Windows 10 Version 1607 for x64-based Systems (KB3213986) on 11/01/2017. I think this is more or less when the problems started. But the past few days I worked on Krita for several hours without any issue.
Created attachment 103517 [details] Krita 3.1.8 log - latest wacom drivers
Waco has finally reorganized their drivers section and I installed the latest drivers for the Intuos 3 (and cintiq UX) series, which was released last January. Still crash after a couple of minutes while painting..
Git commit 893bc79a0be4ce91f82c8eceff2cd51da2d85e72 by Boudewijn Rempt. Committed on 19/01/2017 at 10:44. Pushed by rempt into branch 'master'. Despite the asserts being of the KIS_ASSERT_RECOVER_NOOP type, they lead to a hard assert without a message being shown in our windows builds. I do not know why that is, but it means that this check gives a crash without any information. So, for now, let's disable the asserts so we can test what is really going on. M +5 -2 libs/brush/kis_qimage_pyramid.cpp https://commits.kde.org/krita/893bc79a0be4ce91f82c8eceff2cd51da2d85e72
It's still a big puzzle, and it must be something related to your setup... I've pushed a change that should soon be built on appveyor. This disables the assert. Please test with tablet log enabled and debugview running so we can check the output of the warning.
Created attachment 103527 [details] Brushes used during the crashes
Created attachment 103528 [details] Brush used during the crashes
http://valdyas.org/~boud/krita-dev2.zip has changed the assert into a safe assert, which means Krita won't halt. I can still reproduce it, but I'm still looking into it, but it's slow going.
Git commit ac257511dbec0a3191bbfdde9d886b70ec6ad574 by Boudewijn Rempt. Committed on 22/01/2017 at 14:35. Pushed by rempt into branch 'master'. Weirdly enough, this bug only occurs on Windows 10 with the latest Wacom drivers and an older Wacom Intuos 3 or Cintiq tablet. At least, that's what we suspect. Somehow the input from this drivers drives the roation sensor crazy, and set rotation to NaN. So, first step: check whether the resulting rect is valid, we now return a 0,0 1x1 rect. Second step: check whether the rotation value happens to be NaN and return 0 in that case. Third step: make sure that the rotationLikeValue() function doesn't return NaN -- that is in the next commit. M +43 -27 libs/brush/kis_qimage_pyramid.cpp https://commits.kde.org/krita/ac257511dbec0a3191bbfdde9d886b70ec6ad574
Git commit f7c4c823a80d8eab6b2e1f053de81e04e7303f1c by Boudewijn Rempt. Committed on 22/01/2017 at 14:38. Pushed by rempt into branch 'master'. This follows up on the previous commit (ac257511dbec0a3191bbfdde9d886b70ec6ad574), which had the wrong header... It wasn't a bug in QTransform, because if you set the transform's rotation to NaN, sure, it'll create an invalid rectangle. M +6 -4 plugins/paintops/libpaintop/kis_curve_option.h M +0 -1 plugins/paintops/libpaintop/kis_pressure_hsv_option.cpp https://commits.kde.org/krita/f7c4c823a80d8eab6b2e1f053de81e04e7303f1c
Git commit f3bcd6c57aae1a93b4d256442ee38c2ae32be9fe by Boudewijn Rempt. Committed on 22/01/2017 at 14:40. Pushed by rempt into branch 'krita/3.1'. Weirdly enough, this bug only occurs on Windows 10 with the latest Wacom drivers and an older Wacom Intuos 3 or Cintiq tablet. At least, that's what we suspect. Somehow the input from this drivers drives the roation sensor crazy, and set rotation to NaN. So, first step: check whether the resulting rect is valid, we now return a 0,0 1x1 rect. Second step: check whether the rotation value happens to be NaN and return 0 in that case. Third step: make sure that the rotationLikeValue() function doesn't return NaN -- that is in the next commit. M +43 -27 libs/brush/kis_qimage_pyramid.cpp https://commits.kde.org/krita/f3bcd6c57aae1a93b4d256442ee38c2ae32be9fe
Git commit 3091f39a5e96ee73e6a156acf3ce64bd744c7df8 by Boudewijn Rempt. Committed on 22/01/2017 at 14:40. Pushed by rempt into branch 'krita/3.1'. This follows up on the previous commit (ac257511dbec0a3191bbfdde9d886b70ec6ad574), which had the wrong header... It wasn't a bug in QTransform, because if you set the transform's rotation to NaN, sure, it'll create an invalid rectangle. M +6 -4 plugins/paintops/libpaintop/kis_curve_option.h M +0 -1 plugins/paintops/libpaintop/kis_pressure_hsv_option.cpp https://commits.kde.org/krita/3091f39a5e96ee73e6a156acf3ce64bd744c7df8