Bug 481140

*** Bug 482269 has been marked as a duplicate of this bug. ***

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

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

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.

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

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

@Oded, what about you?

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

(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.

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

*** Bug 499002 has been marked as a duplicate of this bug. ***

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.

A possibly relevant merge request was started @ https://invent.kde.org/graphics/gwenview/-/merge_requests/329

*** Bug 499485 has been marked as a duplicate of this bug. ***

A possibly relevant merge request was started @ https://invent.kde.org/graphics/gwenview/-/merge_requests/330

Git commit ee179a5de052a2e0502285ff53a4255c5c9dd094 by Pedro Hernandez.
Committed on 02/05/2025 at 02:48.
Pushed by merritt into branch 'master'.

Fix crash when crop area is smaller than handles

The crash occurs due to a failed assertion in `qBound()` that tests
`Q_ASSERT(!(max < min))`. This happens when computing the position
of the crop area middle handles (top center, bottom center, left
 center, right center) and they overlap with the corner handles.

The fix proposed is to check if there is enough room within the
respective axis (width or height) for a middle handle to be
repositioned when the crop area is not completely inside the
viewport. This preserves the existing functionality added in
commits `307816e2819f` and `e61ce1e2886c6`.

M  +10   -4    lib/crop/croptool.cpp

https://invent.kde.org/graphics/gwenview/-/commit/ee179a5de052a2e0502285ff53a4255c5c9dd094