| Summary: | Select gradient fill for vector shape stroke, krita freezes | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | acc4commissions |
| Component: | Layers/Vector | Assignee: | Dmitry Kazakov <dimula73> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | 10neschip, ahab.greybeard, amoorea77, elngsoup, griffin-barrett, halla, philippe.bourin, snopmark |
| Priority: | NOR | Keywords: | regression, release_blocker, triaged |
| Version: | nightly build (please specify the git hash!) | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | https://invent.kde.org/kde/krita/commit/d45cb95b1bfdafeb8ade9d2c2f85acf992d40807 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: |
4.4.7 crash log
5.0.0 Crash Log The initial vector shape |
||
|
Description
acc4commissions
2019-10-09 04:24:15 UTC
I'm sorry, but I cannot reproduce that issue with a build from today's git master. Still happens in git 56ee905. Create a vector shape > Select > Tool Options > Stroke > Gradient fill > Freeze. I can confirm this for the 4.2.7.1 release appimage and for the latest nightly build appimage 4.3.0-prealpha (git 0cc05e0) It happens if the shape is created and then stroke fill of gradient is immediately applied - lock up with 0% CPU usage. If you use a gradient fill on the shape (main body) fill first, this works fine and then a subsequent gradient fill on the stroke will work ok. If you then Close the image and Create a new one, it shows the same lock up behaviour. I am using Krita Plus 4.2.7-beta1 (git e9b2584) released Oct 12, and it happens to me as well. Windows 10 Home 64-bit. 1. Created a shape with the "Rectangle Tool" on a Vector Layer. 2. Use "Select Shapes Tool" to select the rectangle. 3. "Tool Options" > "Stroke" tab > select "Gradient fill." Krita Plus freezes/crashes at this point, only way to close it out is through Windows Task Manager. *** Bug 412946 has been marked as a duplicate of this bug. *** The latest Dec 09 4.3.0 prealpha appimage git 0e62d4e has introduced changed behaviour (and an extra problem with fill colour). I also include additional information about behaviour I've noticed. STEPS TO DEMONSTRATE: 1. Using 4.2.8, make a vector rectangle and try to set the stroke to gradient. Notice that krita locks up with no CPU activity. 2. Using 4.2.6, make a vector rectangle with stroke as a gradient and Save the image. 3. Using 4.2.8, Open the file made in Step 2 This is displayed correctly but when it's selected it becomes filled with black. It can then be moved around. If you try to change the fill colour it changes for a fraction of a second then goes back to black. Using the stroke gradient control handle, you can adjust the gradient of the stroke. You can also change the stroke type to any of the options and back to gradient again. 4. Draw an additional vector rectangle and try to set the stroke to gradient. Notice that krita locks up with no CPU activity. 5. Using the 4.3.0, prealpha, Open the file made in Step 2. This is similar to the Step 3 situation but the fill colour selector has empty palette cells. Colours can be chosen from the palette name drop down list but the change reverts to black. For stroke colour fills, a colour change works and does not revert. 6. Draw an additional vector rectangle and try to set the stroke to gradient. Notice that krita locks up with no CPU activity. 7. Using the 4.3.0 prealpha, make a vector rectangle. Notice that despite the colour drop down having problems as noted in Step 5, you can change the fill colour. Try to set the stroke to gradient. Notice that krita locks up with no CPU activity. *** Bug 415427 has been marked as a duplicate of this bug. *** It looks like there's mutex contention: 1 syscall syscall.S 38 0x7fbc42164839 2 QtLinuxFutex::_q_futex qfutex_p.h 92 0x7fbc42a85e55 3 QtLinuxFutex::futexWait<QBasicAtomicPointer<QMutexData>> qfutex_p.h 107 0x7fbc42a85e55 4 lockInternal_helper<false> qmutex_linux.cpp 142 0x7fbc42a85e55 5 QBasicMutex::lockInternal qmutex_linux.cpp 159 0x7fbc42a85e55 6 QMutex::lock qmutex.cpp 227 0x7fbc42a8603b 7 QMutexLocker::QMutexLocker qmutex.h 206 0x7fbc400abdea 8 KoShapeManager::notifyShapeChanged(KoShape *) [clone .localalias.216] KoShapeManager.cpp 691 0x7fbc400a6ad0 9 KoShape::notifyChanged() KoShape.cpp 821 0x7fbc400954df 10 KoShape::setBackground KoShape.cpp 1077 0x7fbc40098b97 11 KoShapeBackgroundCommand::redo() atomic_base.h 295 0x7fbc401470b5 12 KUndo2Command::redoMergedCommands() kundo2stack.cpp 398 0x7fbc3f628773 13 KUndo2QStack::push(KUndo2Command *) kundo2stack.cpp 711 0x7fbc3f6294e8 14 KoFillConfigWidget::colorChanged() KoFillConfigWidget.cpp 530 0x7fbc463d5870 15 KoFillConfigWidget::qt_static_metacall(QObject *, QMetaObject::Call, int, void * *) moc_KoFillConfigWidget.cpp 149 0x7fbc4658d895 16 QMetaObject::activate qobject.cpp 3809 0x7fbc42c9b8d5 17 QMetaObject::activate qobject.cpp 3660 0x7fbc42c9bf97 18 KisSignalCompressor::timeout moc_kis_signal_compressor.cpp 152 0x7fbc4440bf60 19 KisSignalCompressor::tryEmitSignalSafely kis_signal_compressor.cpp 170 0x7fbc44400eb5 20 KisSignalCompressor::start kis_signal_compressor.cpp 104 0x7fbc444010ba ... <More> I am getting this issue as well.
Add Debian 10 LXDE to the list
Krita
Version: 4.3.0-prealpha (git 7b6c721)
Languages: en_CA, en, en, en_CA, en
Hidpi: true
Qt
Version (compiled): 5.12.5
Version (loaded): 5.12.5
OS Information
Build ABI: x86_64-little_endian-lp64
Build CPU: x86_64
CPU: x86_64
Kernel Type: linux
Kernel Version: 5.4.0-2-amd64
Pretty Productname: Debian GNU/Linux bullseye/sid
Product Type: debian
Product Version: unknown
OpenGL Info
Vendor: "Intel Open Source Technology Center"
Renderer: "Mesa DRI Intel(R) Haswell Mobile "
Version: "3.0 Mesa 19.2.6"
Shading language: "1.30"
Requested format: QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize -1, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize -1, samples -1, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile)
Current format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 0, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 0, stencilBufferSize 0, samples -1, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile)
Version: 3.0
Supports deprecated functions true
is OpenGL ES: false
QPA OpenGL Detection Info
supportsDesktopGL: true
supportsOpenGLES: true
isQtPreferOpenGLES: false
Hardware Information
GPU Acceleration: none
Memory: 31800 Mb
Number of Cores: 8
Swap Location: /tmp
Current Settings
Current Swap Location: /tmp
Undo Enabled: 1
Undo Stack Limit: 30
Use OpenGL: 0
Use OpenGL Texture Buffer: 1
Use AMD Vectorization Workaround: 0
Canvas State: OPENGL_SUCCESS
Autosave Interval: 900
Use Backup Files: 1
Number of Backups Kept: 1
Backup File Suffix: ~
Backup Location: Same Folder as the File
Use Win8 Pointer Input: 0
Use RightMiddleTabletButton Workaround: 0
Levels of Detail Enabled: 0
Use Zip64: 0
Display Information
Number of screens: 1
Screen: 0
Name: eDP-1
Depth: 24
Scale: 1
Resolution in pixels: 1920x1080
Manufacturer: AU Optronics
Model:
Refresh Rate: 60
I confirm the bug with Krita 4.2.8 regular and nightly built (regular) under windows 10 64 bit professional. STEPS TO REPRODUCE 1. create any vector shape. 1. Select gradient fill for vector shape stroke. 2. krita freezes. I can't do anything so I have to kill the process. Dmitry, please take a look. the bug is present in 4.2 branch only. It is not reproducible in master... Git commit 7f4401a0219a8e63670a7db9ecc1dba05fdbc615 by Dmitry Kazakov. Committed on 24/02/2020 at 16:30. Pushed by dkazakov into branch 'krita/4.2'. Fix deadlocks in KoShapeManager updateTree() can emit shapeChanged() signals. And in general, we shouldn't emit any signal with a lock held. M +21 -16 libs/flake/KoShapeManager.cpp https://invent.kde.org/kde/krita/commit/7f4401a0219a8e63670a7db9ecc1dba05fdbc615 Git commit d45cb95b1bfdafeb8ade9d2c2f85acf992d40807 by Dmitry Kazakov. Committed on 25/02/2020 at 11:36. Pushed by dkazakov into branch 'master'. Fix deadlocks in KoShapeManager updateTree() can emit shapeChanged() signals. And in general, we shouldn't emit any signal with a lock held. # Conflicts: # libs/flake/KoShapeManager.cpp M +23 -17 libs/flake/KoShapeManager.cpp https://invent.kde.org/kde/krita/commit/d45cb95b1bfdafeb8ade9d2c2f85acf992d40807 After the patch, when I select the 'gradient' for stroke, the 'fill' automatically becomes 'Solid', and I can't change the color of the fill or change is to 'None'. After the patch, when I select the 'gradient' for stroke, the 'fill' automatically becomes 'Solid', and I can't change the color of the fill or change is to 'None'.(In reply to acc4commissions from comment #15) > After the patch, when I select the 'gradient' for stroke, the 'fill' > automatically becomes 'Solid', and I can't change the color of the fill or > change is to 'None'. When this happens, the color of the fill is the first gradient color of the stroke. And as I said it cannot be changed, unless you also select the gradient for fill. I'm not sure I described it correctly. :P Hope I did. I can confirm the observations in Comment 15 and Comment 16 for Version: 4.3.0-prealpha (git 5619916) Windows portable .zip. After applying a gradient to the stroke, you can fill the shape with a gradient or a solid colour but not an empty fill. If you fill with a solid colour then that is always the main colour of the stroke gradient. If you try to change it then it shows the new colour for a fraction of a second before reverting to the stroke gradient colour (assuming a FG to transparent gradient on the stroke. This is the case if you use the Tool Option colour selctor or the Advanced Colour Selector. If you do any other kind of gradient on the stroke, the body fill becomes black and can't be changed. I'm having this issue with Krita 4.4.5. SUMMARY Crashes when gradient filling vector image STEPS TO REPRODUCE 1. New vector layer. 2. Draw a rectangle. 3. Select rectangle. 4. Tool options. 5. Gradient 6. Crashes when you try to scroll down, or sometimes a few moments after scrolling down. SOFTWARE/OS VERSIONS Windows: 10 ADDITIONAL INFORMATION Attempted to allocate more more memory to Krita. Alllcated 90% of 32 MB RAM. No change. I have reproduced this as described in Comment 18 with the 4.4.5 appimage on Debian 10. It doesn't happen every time. Once, there was a short lived lockup of about 2 seconds then all worked normally. Once there was a lockup of about 5 seconds followed by a crash. The Usage Log showed: KRITA DID NOT CLOSE CORRECTLY I wasn't doing terminal logging. I'll try to do more investigation later. With the 4.4.7 appimage on Debian 10: After applying a gradient fill in the Tool Options docker, the gradient was applied and I adjusted its start point with no problem. The Tool Options docker then locked up and would not respond. The menu bar did respond by giving drop down items. After about 5 seconds total time, the Tool Options docker was responsive and trying to apply a new gradient caused a crash. Terminal output: double free or corruption (out) Aborted Created attachment 140614 [details]
4.4.7 crash log
The same result with the 4.4.7 and 5.0.0-prealpha (git ae8ee40c07) portable .zip on Windows 10.
I had to repeat the steps a few times to get a crash with 5.0.0 but 4.4.7 crashed the first time.
I've attached the crash logs.
Created attachment 140615 [details]
5.0.0 Crash Log
Hi, Ahab! Could you please attach a testing file that lets you reproduce the problem? I tested on both Windows and Linux (with ASAN) and I cannot reproduce the issue :( Created attachment 140633 [details]
The initial vector shape
Hi Dimitry,
I've just tried it with the Aug 10 5.0.0-prealpha (git 255469219a1) portable .zip and could not induce it after many attempts and manipulations.
With the 4.4.7 portable .zip, it happened after the second attempt where I switched from a gradient fill to a solid colour fill, then deselected the shape, selected the shape and applied a gradient fill.
After a restart, I could do it again after one attempt.
I've attached the .kra image file I started from and this is the same 'starting point' for my previous tests.
You have to keep trying it but 4.4.7 seems easier to crash.
Then I think it's fixed with Krita 5? @Halla With the Sept 06 5.1.0-prealpha (git 9202fb2) appimage, I can't induce a crash or lock up or other incorrect behaviour. It would seem so. |