Summary: | Frequent Crash when creating a second new file of size 2048 x 2048 or greater | ||
---|---|---|---|
Product: | [Applications] krita | Reporter: | Ahab Greybeard <ahab.greybeard> |
Component: | Usability | Assignee: | Dmitry Kazakov <dimula73> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | halla |
Priority: | NOR | ||
Version: | 4.3.0-beta1 | ||
Target Milestone: | --- | ||
Platform: | Debian stable | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/graphics/krita/commit/8e8303429030004a1cbe262945e653515eef3a78 | Version Fixed In: | |
Attachments: | Desktop and laptop logs - 4.3.0-beta2 (git e2b62dc) |
Description
Ahab Greybeard
2020-05-14 16:30:19 UTC
I can confirm with the appimage, though not with my local build. But that assert is a safe assert, so it shouldn't even close krita: https://invent.kde.org/kde/krita/-/merge_requests/338 As for why the assert happens, I'll ask dmitry to look at this bug. *** Bug 422114 has been marked as a duplicate of this bug. *** Well, I cannot reproduce this crash. Neither on Windows nor on Linux (neither in home-built 4.3 nor in 4.3 beta appimage) :( Hi, Ahab! Could you please check this AppImage and provide me the terminal output of it? https://yadi.sk/d/L12GXqThVTx7Gw It might give me more info for the crash :) Git commit 5aef0e99a7b64a8cdb6970803e9c080d47e918e6 by Dmitry Kazakov. Committed on 29/05/2020 at 15:11. Pushed by dkazakov into branch 'master'. Make sanity check in CanvasSwitcher less strict I couldn't reproduce the crash, but the mechanics happens like that: 1) KisCanvas2::setCanvasWidget() adds the canvas to the list of the tracked ones and continues loading process. 2) Some other canvas gets activated by spontaneous SetFocus event (Note: I haven't managed to reproduce that!) 3) KisMainWindow::addView() registers the canvas at the input manager again. But since some other canvas has been activated by a spontaneous event, d->canvas is not equal to canvas anymore. Possible solutions: Option A: Remove double registration of the canvas in the input manager and do it only once either in KisCanvas::setCanvasWidget() or in KisMainWindow Option B: Justremove the sanity check. But this way we may miss real bugs that may happen because of double initialization of the canvas. M +7 -2 libs/ui/input/kis_input_manager_p.cpp https://invent.kde.org/graphics/krita/commit/5aef0e99a7b64a8cdb6970803e9c080d47e918e6 Git commit e09e59548481b32f025c64f9b322bd28ab6ddc9e by Dmitry Kazakov. Committed on 29/05/2020 at 15:11. Pushed by dkazakov into branch 'master'. Remove double initialization of the inut manager on image creation The initialization in KisCanvas2::setCanvasWidget() was intended only for the case when the canvas type is switched (opengl<->qpainter) and it shouldn't trigger during normal canvas creation process. This patch is too dangerous for 4.3.0 release, it should be pushed into 4.3 branch only for 4.3.1 release. M +14 -10 libs/ui/canvas/kis_canvas2.cpp https://invent.kde.org/graphics/krita/commit/e09e59548481b32f025c64f9b322bd28ab6ddc9e Git commit 4f2ceb136cbf90536d3435174359e61db4e28351 by Dmitry Kazakov. Committed on 29/05/2020 at 15:12. Pushed by dkazakov into branch 'krita/4.3'. Make sanity check in CanvasSwitcher less strict I couldn't reproduce the crash, but the mechanics happens like that: 1) KisCanvas2::setCanvasWidget() adds the canvas to the list of the tracked ones and continues loading process. 2) Some other canvas gets activated by spontaneous SetFocus event (Note: I haven't managed to reproduce that!) 3) KisMainWindow::addView() registers the canvas at the input manager again. But since some other canvas has been activated by a spontaneous event, d->canvas is not equal to canvas anymore. Possible solutions: Option A: Remove double registration of the canvas in the input manager and do it only once either in KisCanvas::setCanvasWidget() or in KisMainWindow Option B: Justremove the sanity check. But this way we may miss real bugs that may happen because of double initialization of the canvas. M +7 -2 libs/ui/input/kis_input_manager_p.cpp https://invent.kde.org/graphics/krita/commit/4f2ceb136cbf90536d3435174359e61db4e28351 Hi, Ahab! The bug should be fixed now, but I would still like to know the actual mechanics of it. Could you still send me the output of the package I shared above? https://bugs.kde.org/show_bug.cgi?id=421518#c4 Created attachment 128909 [details]
Desktop and laptop logs - 4.3.0-beta2 (git e2b62dc)
Hi Dmitry,
I've attached the terminal output and also the logs, including logs from my laptop.
The laptop is at the same Debian 10 full update state (i.e today) as the desktop PC.
However, the laptop can handle two new A4(300 ppi) documents but gives a Safe Assert for two 4096 x 4096 documents.
The desktop gives Safe Assert (non crash, can be Ignored) for two new A4(300 ppi) documents.
The only obvious difference is the graphics components and I include the laptop system info log.
Now, the desktop gives a Safe Assert on alternate new A4(300 ppi) documents.
Hi, Ahab! What desktop environment you use? And do you click on the "Create" button with a mouse or with a tablet? It looks like the your desktop environment generates a different flow of events, so I cannot reproduce it :) I'll make one more package for you now. Hi Dmitry, My desktop environment is MATE 1.20.4 and I used a mouse for everything. Are you interested in the laptop behaviour or should I just concentrate on my PC? Hi, Ahab! Could you check if you have the assert in this AppImage: https://yadi.sk/d/-04NVuxnGN6q7Q Does it fix the assert? I have pushed the fix to 5.0, but I will not push it to 4.3.0, because it is a little dangerous. I'll merge it right after the release. Hi Dmitry, With the (git a0ed0b7) appimage, I see no asserts even if I create six A3(600 dpi) images. On saving and on opening four 4096 x 4096 images, I see terminal messages of the type: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 3066, resource id: 12630685, major code: 40 (TranslateCoords), minor code: 0 The sequence and resource id are different every time. I've no idea what those messages mean but it's now creating, saving and opening with no apparent problems - thank you :) XCB warnings are unrelated, and they seem to be harmless :) Then it looks like the bug is fixed, though the fix will be only in 4.3.1 ;) Git commit 8e8303429030004a1cbe262945e653515eef3a78 by Dmitry Kazakov. Committed on 02/06/2020 at 09:34. Pushed by dkazakov into branch 'krita/4.3'. Remove double initialization of the inut manager on image creation The initialization in KisCanvas2::setCanvasWidget() was intended only for the case when the canvas type is switched (opengl<->qpainter) and it shouldn't trigger during normal canvas creation process. This patch is too dangerous for 4.3.0 release, it should be pushed into 4.3 branch only for 4.3.1 release. M +14 -10 libs/ui/canvas/kis_canvas2.cpp https://invent.kde.org/graphics/krita/commit/8e8303429030004a1cbe262945e653515eef3a78 |