So, this is quite similar to bug #2273828 as @aleasto said at matrix KDE-SIG room: we backported "QQuickSelectionRectangle: Fix crash when target is null" which fixes the systemmonitor crash when showing the details sidebar with an application already selected, but it still occasionally crashes when selecting an application after the sidebar was already opened the result still Plasma System Monitor crashes with segmentation fault, but now just a little latter.

FinalBlocker +1

AGREED AcceptedFinalBlocker

Discussed during the 2024-04-08 blocker review meeting [1]:

"For all release-blocking desktop / arch combinations, the following applications must start successfully and withstand a basic functionality test: ...". system monitor is not in the current list, but there is a strong consensus at the meeting (including KDE SIG folks) that this was an oversight in drafting the list and it should always have been there. We will amend the list, and accept this bug in the meantime

[1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-04-08/f40-blocker-review.2024-04-08-16.00.html

The following votes have been closed:

• Accepted FinalBlocker (+1, 0, -0)
  • +1 by geraldosimiao

system monitor is not in the current list, but there is a strong consensus at the meeting (including KDE SIG folks) that this was an oversight in drafting the list

It definitely wasn't an oversight, when I was drafting the list. The importance of system monitor is much lower than the importance of the other apps in the list. I'd say that some apps which aren't in the list, e.g. the whole office suite, is more important for an average user than the system monitor. But I wasn't at the meeting, so I didn't have a vote, my bad :-)

Just clarifying that it wasn't an oversight, at least from my part.

Based on further testing by KDE SIG folks, I think we should revote this. @farchord , @marcdeop and @derekenz were all able to reproduce this, but they said it took a fairly artificial amount of very fast interactions with the app to make it crash. They each said the amount of effort it took doesn't "feel" blocker-y, i.e. it's kinda outside the scope of 'basic functionality'.

REVOTE FinalBlocker

Given that it's pretty difficult to trigger,

FinalBlocker -1

I'm the original reporter of the cited https://bugzilla.redhat.com/show_bug.cgi?id=2273737#c0. I wouldn't consider this a blocker due to the fact that it's only occurred once for me, and it doesn't cause any loss of data.

However, I shall note that I didn't cause the bug doing anything particularly strange or quickly, so I expect that many others shall experience it, should f40 ship with it.

Yeah, I reproduced this too. And as I said at the meeting it is not an instant crash, it's fair to say this bug isn't stopping a regular use from system monitor.

FinalBlocker -1

But I think this deserve a FE in case we have a fix.

FinalFE +1

Yeah we have a bug opened upstream with quite a bit of information, as soon as a fix is out we'll fix it

I'm fine with this state, as I couldn't actually reproduce it today.

FinalFE +1

FinalBlocker -1
FinalFE +1
AGREED RejectedFinalBlocker
AGREED AcceptedFinalFE

The following votes have been closed:

• Rejected FinalBlocker (+0, 0, -3)
  • -1 by kevin, geraldosimiao, adamwill
• Accepted FinalFreezeException (+3, 0, -0)
  • +1 by geraldosimiao, ngompa, adamwill

Release F40 is no longer tracked by BlockerBugs, closing this ticket.