Bug 509782

Summary:	Spectacle crashes when it runs out of VRAM
Product:	[Applications] Spectacle	Reporter:	Björn Lindqvist <bjourne>
Component:	General	Assignee:	Noah Davis <noahadvs>
Status:	RESOLVED WORKSFORME
Severity:	crash	CC:	kde, kdedev
Priority:	NOR
Version First Reported In:	6.4.5
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Björn Lindqvist 2025-09-22 13:32:45 UTC

My systemd journal explains it:

sep 22 15:22:17 bjourne systemd[667]: Starting Spectacle screenshot capture utility...
sep 22 15:22:17 bjourne systemd[667]: Started Spectacle screenshot capture utility.
sep 22 15:22:17 bjourne spectacle[236569]: QWaylandGLContext::makeCurrent: eglError: 0x3003, this: 0x55690e62af60
sep 22 15:22:17 bjourne spectacle[236569]: QRhiGles2: Failed to make context current. Expect bad things to happen.
sep 22 15:22:17 bjourne spectacle[236569]: Failed to create RHI (backend 2)
sep 22 15:22:17 bjourne spectacle[236569]: Failed to initialize graphics backend for OpenGL.
sep 22 15:22:17 bjourne systemd-coredump[236581]: Process 236569 (spectacle) of user 1000 terminated abnormally with signal 6/ABRT, processing...
sep 22 15:22:17 bjourne systemd[1]: Started Process Core Dump (PID 236581/UID 0).

My Quadro P400 has only 2 GB VRAM which is not enough for memory-hungry Wayland. That is fine, but it would be good if Spectacle could handle it without core dumping. A dialog box saying "Not enough VRAM to take screenshots" or something would be nice.

Comment 1 TraceyC 2025-09-22 16:40:47 UTC

Thanks for the bug report, and the journal logs.

As the message at the top of the summary says, if something crashed, we need a backtrace of it so we can figure out what's going on and prevent the crash. Can you please attach a backtrace of the crash using the coredumpctl command-line program, as detailed in https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl ?

Thanks.

Comment 2 Bug Janitor Service 2025-10-07 03:47:02 UTC

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

Comment 3 Björn Lindqvist 2025-10-09 14:25:17 UTC

The backtrace is right there in the systemd log.

Comment 4 TraceyC 2025-10-09 16:19:46 UTC

The journal has reference to the crash, but that is not a backtrace.

We need a backtrace of the crash using the coredumpctl command-line program, as detailed in https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl . Thanks.

Comment 5 Björn Lindqvist 2025-10-12 11:46:44 UTC

I can't reproduce the crash willy-nilly hence can't provide you with a complete stack trace. However, the four relevant log lines are clearly enough to detect exactly where in spectacle it crashes.

Comment 6 TraceyC 2025-10-14 16:27:27 UTC

If you still have a coredump, you can create a backtrace from that.

Comment 7 Bug Janitor Service 2025-10-29 03:47:49 UTC

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

Comment 8 Bug Janitor Service 2025-11-13 03:47:45 UTC

🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.