Fix: SplashScreen::SetText null Pango context crash on GTK #504

Open
opened 2026-04-05 16:21:52 +02:00 by MrUnknownDE · 0 comments
Owner

Originally created by @panther757 on 3/3/2026

Problem

On GTK/Linux, SplashScreen::SetText() can crash with SIGSEGV inside wxDC::GetTextExtent(). The root cause is a null Pango layout context in the wxMemoryDC, which arises when SelectObject()
fails silently.

There is also a heap-use-after-free (confirmed with ASan): the splash screen has a 1500ms auto-close timer. If a nested GTK event loop runs during on_init_inner() — for example from a wxASSERT
dialog — the timer fires, wxPendingDelete frees the SplashScreen, and the subsequent scrn->SetText() call in on_init_inner() writes to freed memory.

This may fix one or more of the existing Pango related crash issues. I used Claude Code to debug the crashes and create fixes.

Fixes

  1. Deep-copy the bitmap before drawing (GetSubBitmap)

wxBitmap(other) is a shallow copy that shares the underlying Cairo surface. If the window display concurrently holds a reference to the same surface, SelectObject() silently fails, leaving the
wxMemoryDC without a valid Pango context.

Replaced with GetSubBitmap() which forces an independent copy of the surface.

  1. Guard SelectObject() failure with memDC.IsOk()

Even with the deep copy, SelectObject() can fail in degenerate conditions. Added an IsOk() check immediately after — if the DC is not usable, return early rather than proceeding to
GetTextExtent() with a null Pango context.

  1. Guard scrn against heap-use-after-free

Bind wxEVT_DESTROY on the SplashScreen to null out a shared_ptr<SplashScreen*>. After wxYield(), re-read scrn from the shared pointer before calling SetText(). This ensures the pointer is never
dereferenced after wxPendingDelete has freed the window.

Platform

GTK/Linux only in practice (Cairo backend, Pango text layout). The changes are cross-platform safe — GetSubBitmap, wxDC::IsOk, and wxEVT_DESTROY are standard wxWidgets APIs available on all
platforms.

Testing

I was previously having crashes every time OrcaSlicer started, but not after these fixes.

Test platform:
Gentoo Linux
Pango 1.57.0
OrcaSlicer 2.3.1 and also latest

*Originally created by @panther757 on 3/3/2026* ## Problem On GTK/Linux, SplashScreen::SetText() can crash with SIGSEGV inside wxDC::GetTextExtent(). The root cause is a null Pango layout context in the wxMemoryDC, which arises when SelectObject() fails silently. There is also a heap-use-after-free (confirmed with ASan): the splash screen has a 1500ms auto-close timer. If a nested GTK event loop runs during on_init_inner() — for example from a wxASSERT dialog — the timer fires, wxPendingDelete frees the SplashScreen, and the subsequent scrn->SetText() call in on_init_inner() writes to freed memory. This may fix one or more of the existing Pango related crash issues. I used Claude Code to debug the crashes and create fixes. ## Fixes 1. Deep-copy the bitmap before drawing (GetSubBitmap) wxBitmap(other) is a shallow copy that shares the underlying Cairo surface. If the window display concurrently holds a reference to the same surface, SelectObject() silently fails, leaving the wxMemoryDC without a valid Pango context. Replaced with GetSubBitmap() which forces an independent copy of the surface. 2. Guard SelectObject() failure with memDC.IsOk() Even with the deep copy, SelectObject() can fail in degenerate conditions. Added an IsOk() check immediately after — if the DC is not usable, return early rather than proceeding to GetTextExtent() with a null Pango context. 3. Guard scrn against heap-use-after-free Bind wxEVT_DESTROY on the SplashScreen to null out a shared_ptr<SplashScreen*>. After wxYield(), re-read scrn from the shared pointer before calling SetText(). This ensures the pointer is never dereferenced after wxPendingDelete has freed the window. ## Platform GTK/Linux only in practice (Cairo backend, Pango text layout). The changes are cross-platform safe — GetSubBitmap, wxDC::IsOk, and wxEVT_DESTROY are standard wxWidgets APIs available on all platforms. ## Testing I was previously having crashes every time OrcaSlicer started, but not after these fixes. Test platform: Gentoo Linux Pango 1.57.0 OrcaSlicer 2.3.1 and also latest
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/OrcaSlicer#504