Created attachment 135707 [details] screenshot of steps - krita stalls briefly then crashes after the last step SUMMARY STEPS TO REPRODUCE 1. Set Snap To to Pixel, Bounding Box, Image Bounds, and Image Center 2. Make a new Text object 3. Add a gradient to the outline OBSERVED RESULT Krita stalls briefly then crashes EXPECTED RESULT Text outline should get a gradient SOFTWARE/OS VERSIONS Windows: 10 Krita: 4.4.2 ADDITIONAL INFORMATION Screenshots of steps in attachments
I can't reproduce on Linux.
(In reply to tomtomtomreportingin from comment #1) > I can't reproduce on Linux. Did you leave the fill text fill as solid or did you have it set to something else - I had my text's fill as a solid color when this bug occured
Still can't reproduce it, sorry. Did you check to see if this seems to happen with all fonts or just the certain font you used?
(In reply to tomtomtomreportingin from comment #3) > Still can't reproduce it, sorry. > Did you check to see if this seems to happen with all fonts or just the > certain font you used? I tested it again with the fonts Impact and Arial. These fonts did not crash Krita immediately upon giving it a gradient outline - however, once I went to change the text's font (to be precise, as soon as I clicked on the font drop-down list), the program crashed. The font I was originally using is called Adam Warren pro by the way
I can't reproduce this with 4.4.2 on Windows 10 using Adam Warren Pro font. Is there a kritacrash.log at -\AppData\Local ?
Created attachment 135989 [details] Crash logs
(In reply to Ahab Greybeard from comment #5) > I can't reproduce this with 4.4.2 on Windows 10 using Adam Warren Pro font. > Is there a kritacrash.log at -\AppData\Local ? I have added the crash log to the attachments of this bug report
I can't help with the crash log but if you're running any other applications as noted in the taskbar, please close them, restart the PC and try again with krita as the only running application.
The bug seems to have something related to RTL support. I cannot reproduce it here though (in LTR environment).
Is this report a duplicate of the crash part of #395808?
I don't think so, the crash seems to be in the destructor of QSvgHandler: 00007FFF8990DCCC 000000000039004D 00000000000000F0 00000000698C62E0 ntdll.dll!0x4dccc RtlpLfhFindClearBitAndSet+0xc4 00007FFF898FB91F 0000000000180000 00007FFF00000000 00000000000000E0 ntdll.dll!0x3b91f RtlpLowFragHeapAllocFromContext+0x25f 00007FFF898FB434 0000000000000000 00000000000000E0 0000000000000001 ntdll.dll!0x3b434 RtlpAllocateHeapInternal+0x994 00007FFF88FE9DA0 00000000000000E0 00000000005F7310 00000000005F75F0 msvcrt.dll!0x19da0 malloc+0x70 000000006FD0728C 0000000000000009 00000000005F7308 000000001E6C2A68 libstdc++-6.dll!0xc728c operator new+0x1c 00007FFF4091B773 0000000000000005 00007FFF17C20AC9 0000000000000000 Qt5Svg.dll!0xb773 QSvgHandler::~QSvgHandler+0x1f03
The backtrace looks sort of like heap corruption to me? Probably needs checking with memcheck or appverifier (In reply to Dmitry Kazakov from comment #9) > The bug seems to have something related to RTL support. I cannot reproduce > it here though (in LTR environment). I don't see anything related to RTL from the screenshots...
I can't trigger any crashes under appverifier on nightly ac1d8bd110, even using the Adam Warren Pro font.
I don't think there's anything we can do here... It's already weird that the crash in QtSvg since we don't actually use that for drawing text or shapes -- it's only used in the svg brush and in the storyboard docker. From the backtrace, it looks like rendering a certain icon for a tool button was broken, but that's deep in Qt. Let's call this a Qt bug...