Bug 481140 - Gwenview crashes when cropping image
Summary: Gwenview crashes when cropping image
Status: ASSIGNED
Alias: None
Product: gwenview
Classification: Applications
Component: general (show other bugs)
Version: 24.05.2
Platform: Neon Linux
: NOR crash
Target Milestone: ---
Assignee: Gwenview Bugs
URL:
Keywords: qt6
: 482269 499002 499485 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-02-09 20:14 UTC by fin-w
Modified: 2025-03-29 02:23 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
A nice picture to reproduce the issue with (170.94 KB, image/jpeg)
2024-12-01 21:34 UTC, Malte S. Stretz
Details
Gimp. Crop tool handles when area is small. (613.40 KB, image/png)
2025-03-12 01:47 UTC, Pedro
Details

Note You need to log in before you can comment on or make changes to this bug.
Description fin-w 2024-02-09 20:14:50 UTC
SUMMARY
Gwenview crashes when I try to crop a PNG image. There seems to be a relationship between the image height and the minimum x / y of the crop. Divide the image height by about 13 for the threshold at which Gwenview will crash. So for images 10 000 pixels in height, Gwenview crashes when the crop box goes below 754, for 4000px it's 302, 800px it's 61 etc. For images under 600px height, Gwenview crashes when the crop box goes below 46. Running Gwenview from Konsole, I get these details when it crashes:

`ASSERT: "!(max < min)" in file /usr/include/x86_64-linux-gnu/qt6/QtCore/qminmax.h, line 46
Aborted (core dumped)`

STEPS TO REPRODUCE
1. Open an image with Gwenview. I have seen this happen with PNG files.
2. Select "Show Editing Tools -> Crop -> Advanced Settings" to show the Size: [x] [y] text boxes.
3. Reduce the x or y crop size number to below about a 13th of the image height.

OBSERVED RESULT
Gwenview freezes, then crashes and closes. 

EXPECTED RESULT
Crop

SOFTWARE/OS VERSIONS
KDE Neon Unstable, Wayland
Gwenview 24.04.70 (whatever's in the "unstable" Neon repository)
KDE Plasma Version: 6.0.80
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.1
Comment 1 popov895 2024-03-11 11:12:37 UTC
*** Bug 482269 has been marked as a duplicate of this bug. ***
Comment 2 fin-w 2024-03-12 20:47:40 UTC
Reporting as confirmed because of the duplicate bug.

I can't check on Neon any more, but for me, this issue is fixed in Gwenview 24.02.0 on this machine:

Operating System: Arch Linux 
KDE Plasma Version: 6.0.1
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.7.9-arch1-1 (64-bit)
Graphics Platform: Wayland
Comment 3 Greg Lepore 2024-03-15 14:58:57 UTC
I'm seeing this on KDE Neon:

Operating System: KDE neon 6.0
KDE Plasma Version: 6.0.2
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.5.0-25-generic (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 2600 Six-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: NV168

Gwenview
Version 24.02.0
Comment 4 fin-w 2024-03-15 20:05:07 UTC
Interesting... I just updated to Plasma 6.0.2 and the problem is still fixed for me on Arch. I wonder if it's unique to KDE neon.
Comment 5 Oded Arbel 2024-07-29 11:29:56 UTC
I believe I have the same issue. Gwenview 24.05.2 on Plasma 6.1.3. Steps:

1. Open an image with Gwenview (could be anything)
2. Hit SHIFT+C to start cropping, or choose from the menu.
3. Make sure "advanced settings" is checked in the crop tool.
4. In the Aspect Ratio field type "20:" (or any number 10 or larger)
5. Type "1"

Observed result:
Gwenview immediately closes.

When running from the terminal, the following text appears at the end of the debug log:

ASSERT: "!(max < min)" in file /usr/include/x86_64-linux-gnu/qt6/QtCore/qminmax.h, line 46
Aborted
Comment 6 fin-w 2024-08-30 17:36:36 UTC
This still seems fixed for me. @Greg, are you still having problems? What system / versions are you using?

For me:
SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 6.1.4
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2
Kernel Version: 6.10.7-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 16 × 12th Gen Intel® Core™ i5-1240P
Memory: 15.3 GiB of RAM
Graphics Processor: Mesa Intel® Graphics
Manufacturer: LENOVO
System Version: ThinkPad T14s Gen 3
Comment 7 fin-w 2024-08-30 17:38:12 UTC
@Oded, what about you?
Comment 8 Greg Lepore 2024-08-30 17:39:42 UTC
Yes, I am still seeing this bug.

QPainter::begin: Paint device returned engine == 0, type: 2
QPainter::setOpacity: Painter not active
QPainter::end: Painter not active, aborted
qt.qpa.wayland: eglSwapBuffers failed with 0x300d, surface: 0x0
ASSERT: "!(max < min)" in file /usr/include/x86_64-linux-gnu/qt6/QtCore/qminmax.h, line 46
Aborted (core dumped)


Operating System: KDE neon 6.0
KDE Plasma Version: 6.1.4
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2
Kernel Version: 6.8.0-40-generic (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 2600 Six-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: NV168
Comment 9 Oded Arbel 2024-08-31 09:31:39 UTC
(In reply to fin-w from comment #7)
> @Oded, what about you?

Yep, still happens on Neon unstable - running gwenview 4:24.08.0+p24.04+vstable+git20240822.0503-0 -- with the repro I posted in comment #5.

Operating System: KDE neon Unstable Edition
KDE Plasma Version: 6.1.80
KDE Frameworks Version: 6.6.0
Qt Version: 6.7.2
Kernel Version: 6.8.0-41-generic (64-bit)
Graphics Platform: Wayland
Processors: 20 × 12th Gen Intel® Core™ i7-12700H
Memory: 31.0 GiB of RAM
Graphics Processor: Mesa Intel® Graphics

Stack trace:

... crash handling stuff trimmed ...
#9  0x000075c1862c7a23 in qt_assert (assertion=assertion@entry=0x75c188991e07 "!(max < min)", file=file@entry=0x75c18898e510 "/usr/include/x86_64-linux-gnu/qt6/QtCore/qminmax.h", line=line@entry=46)
    at /usr/src/qt6-base-6.7.2-0zneon+24.04+noble+unstable+build1/src/corelib/global/qassert.cpp:68
#10 0x000075c188899a73 in qBound<int>(int const&, int const&, int const&) [clone .part.0] [clone .lto_priv.0] (max=<optimized out>, val=<optimized out>, min=<optimized out>) at /usr/include/x86_64-linux-gnu/qt6/QtCore/qminmax.h:46
#11 0x000075c18889a627 in qBound<int> (max=<optimized out>, val=<optimized out>, min=<optimized out>) at /usr/src/gwenview-4:24.08.0+p24.04+vstable+git20240822.0503-0/lib/document/document.cpp:397
#12 Gwenview::CropToolPrivate::handleViewportRect (this=0x5fcb98ffbbd0, handle=...) at /usr/src/gwenview-4:24.08.0+p24.04+vstable+git20240822.0503-0/lib/crop/croptool.cpp:101
#13 0x000075c1888b6751 in Gwenview::CropTool::paint (this=0x5fcb9af913d0, painter=0x7ffd5cabe970) at /usr/src/gwenview-4:24.08.0+p24.04+vstable+git20240822.0503-0/lib/crop/croptool.cpp:277
... internal Qt event dispatching ...

I can attach the full stack trace, if you want, or any other relevant stuff - including building patched versions.
Comment 10 Malte S. Stretz 2024-12-01 21:34:36 UTC
Created attachment 176271 [details]
A nice picture to reproduce the issue with

I can reproduce this issue (Gwenview 24.08.3) with the attached image and when I try to set width or height to a one-digit value.

Operating System: KDE neon 6.2
KDE Plasma Version: 6.2.3
KDE Frameworks Version: 6.8.0
Qt Version: 6.8.0
Kernel Version: 6.8.0-49-generic (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i5-6300U CPU @ 2.40GHz
Memory: 7,6 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 520
Manufacturer: LENOVO
Product Name: 20F5S1H800
System Version: ThinkPad X260
Comment 11 TraceyC 2025-01-27 18:44:02 UTC
*** Bug 499002 has been marked as a duplicate of this bug. ***
Comment 12 Pedro 2025-03-12 01:47:29 UTC
Created attachment 179328 [details]
Gimp. Crop tool handles when area is small.

The crash occurs when computing the position of the crop handles (the small squares used to control the area to crop). When the area is small for the crop handles, we'll see that assertion is not met because there is an overlap.
At first glance, I think this is a simple problem that might get tricky because we need first to define what would be the behavior when the handles don't fit, and after that we could determine the amount of work required. For instance, currently, the size of the handles is fixed, 15 pixels and I looked at Gimp to see how it handles this problem. What I found is that the handles are adaptive. They have a default size that might change depending on the current zoom value and the current crop area. They also move outside the crop area when there is not enough room for all of them. We might try this approach but I think right now Gwenview doesn't have some sort of padding for the images in case the handles move outside the crop area.

More research is required. I'll try to give it a shot but we need to define what will be the behavior of the crop handles.

I attached an image displaying an example in Gimp.
Comment 13 Bug Janitor Service 2025-03-26 06:12:26 UTC
A possibly relevant merge request was started @ https://invent.kde.org/graphics/gwenview/-/merge_requests/329
Comment 14 Pedro 2025-03-29 02:23:56 UTC
*** Bug 499485 has been marked as a duplicate of this bug. ***