Dear Maintainer,

After upgrading LabPlot to version 2.12, the application cannot be launched anymore.

Attempting to launch it from the command line leads to the instant "Segmentation fault" crash without any preceding or subsequent notifications, or logging messages.

Tested and reproduced on two different machines with different hardware (desktop and laptop), to the same behaviour.

The package can be successfully rebuilt from sources without any errors, but the local build reproduces the same crash.

Did a bit of experimentation, using weekly LiveUSB build of Testing (KDE flavor) from
2025-05-12 and booting into it on three different machines. The environment has been kept
as-is, only updating mandatory dependencies during labplot installation.

In all cases the native version installed from Testing/Unstable repos segfaulted instantly
in the same way.

However, Flatpak and AppImage builds of labplot-2.12 launch and work without any problems,
as intended.

Since it was flagged as "unreproducible" I wanted to chime in that
this happens for me too.

Debian 13.4, GNOME 48, Wayland, . Just installed labplot and it didn't
start so I did some debugging without reaching any conclusions.

Starting from a terminal shows a splash window a fraction of a second
(faster than it's possible to see) and is then terminated:

❯ labplot
fish: Job 1, 'labplot' terminated by signal SIGSEGV (Address boundary error)

QT_QPA_PLATFORM=xcb does not make a difference.

Running in gdb shows that it's crashing after the splash screen and
another black window: https://i.imgur.com/pnLUjH7.jpeg


The backtrace doesn't look useful:

(gdb) run
Starting program: /usr/bin/labplot
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffea6da6c0 (LWP 80908)]
[New Thread 0x7fffe9ed96c0 (LWP 80909)]
[New Thread 0x7fffe3fff6c0 (LWP 80910)]
[New Thread 0x7fffe37fe6c0 (LWP 80911)]
[New Thread 0x7fffe2ffd6c0 (LWP 80912)]
[New Thread 0x7fffe27fc6c0 (LWP 80914)]

Thread 1 "labplot" received signal SIGSEGV, Segmentation fault.
0x00005555557e8304 in ?? ()
(gdb) bt full
#0  0x00005555557e8304 in ??? ()
#1  0x00005555557e8c70 in ??? ()
#2  0x000055555579389e in ??? ()
#3  0x00007ffff3a35ca8 in __libc_start_call_main
    (main=main@entry=0x555555791f10, argc=argc@entry=1,
argv=argv@entry=0x7fffffffe308)
    at ../sysdeps/nptl/libc_start_call_main.h:58
        self = <optimized out>
        result = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737488347912,
5020425957166467729, 0, 140737488347928, 140737354125312,
93825007010456, -5020425958104184175, -5020451964185687407},
mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x7fffffffe308, 0x1},
data = {prev = 0x0, cleanup = 0x0, canceltype = -7416}}}
        not_first_call = <optimized out>
#4  0x00007ffff3a35d65 in __libc_start_main_impl
    (main=0x555555791f10, argc=1, argv=0x7fffffffe308, init=<optimized
out>, fini=<optimized out>, rtld_fini=<optimized out>,
stack_end=0x7fffffffe2f8) at ../csu/libc-start.c:360
#5  0x00005555557bb121 in ??? ()



I also ran it in valgrind, I don't know which flags to use but at
least there's something:

❯ valgrind labplot
==81335== Memcheck, a memory error detector
==81335== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==81335== Using Valgrind-3.24.0 and LibVEX; rerun with -h for copyright info
==81335== Command: labplot
==81335==
==81335== Syscall param writev(vector[0]) points to uninitialised byte(s)
==81335==    at 0x85DD9EE: __syscall_cancel_arch (syscall_cancel.S:56)
==81335==    by 0x85D2667: __internal_syscall_cancel (cancellation.c:49)
==81335==    by 0x85D26AC: __syscall_cancel (cancellation.c:75)
==81335==    by 0x86534E8: writev (writev.c:26)
==81335==    by 0x4F5C015: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==81335==    by 0x4F5C8B0: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==81335==    by 0x4F5DBC4: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==81335==    by 0x4F5DC44: xcb_wait_for_reply (in
/usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==81335==    by 0x1242FB99:
QXcbConnection::initializeScreensFromMonitor(xcb_screen_iterator_t*,
int, QXcbScreen**, bool) (in
/usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.8.2)
==81335==    by 0x124317C7: QXcbConnection::initializeScreens(bool)
(in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.8.2)
==81335==    by 0x12421D50:
QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool, unsigned
int, char const*) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.8.2)
==81335==    by 0x12447135:
QXcbIntegration::QXcbIntegration(QList<QString> const&, int&, char**)
(in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.8.2)
==81335==  Address 0x11db7d15 is 4,533 bytes inside a block of size
21,176 alloc'd
==81335==    at 0x484BBA3: calloc (vg_replace_malloc.c:1675)
==81335==    by 0x4F5B9C2: xcb_connect_to_fd (in
/usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==81335==    by 0x4F60240: xcb_connect_to_display_with_auth_info (in
/usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==81335==    by 0x98070C1: _XConnectXCB (in
/usr/lib/x86_64-linux-gnu/libX11.so.6.4.0)
==81335==    by 0x97F6B44: XOpenDisplay (in
/usr/lib/x86_64-linux-gnu/libX11.so.6.4.0)
==81335==    by 0x1242AF26:
QXcbBasicConnection::QXcbBasicConnection(char const*) (in
/usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.8.2)
==81335==    by 0x12421B02:
QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool, unsigned
int, char const*) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.8.2)
==81335==    by 0x12447135:
QXcbIntegration::QXcbIntegration(QList<QString> const&, int&, char**)
(in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.8.2)
==81335==    by 0x486E46F: ??? (in
/usr/lib/x86_64-linux-gnu/qt6/plugins/platforms/libqxcb.so)
==81335==    by 0x70FA507:
QGuiApplicationPrivate::createPlatformIntegration() (in
/usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.8.2)
==81335==    by 0x70FC0A7:
QGuiApplicationPrivate::createEventDispatcher() (in
/usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.8.2)
==81335==    by 0x78EEC55: QCoreApplicationPrivate::init() (in
/usr/lib/x86_64-linux-gnu/libQt6Core.so.6.8.2)
==81335==
==81335== Invalid read of size 8
==81335==    at 0x39C304: ??? (in /usr/bin/labplot)
==81335==    by 0x39CC6F: ??? (in /usr/bin/labplot)
==81335==    by 0x34789D: ??? (in /usr/bin/labplot)
==81335==    by 0x856CCA7: (below main) (libc_start_call_main.h:58)
==81335==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==81335==
==81335==
==81335== Process terminating with default action of signal 11 (SIGSEGV)
==81335==  Access not within mapped region at address 0x0
==81335==    at 0x39C304: ??? (in /usr/bin/labplot)
==81335==    by 0x39CC6F: ??? (in /usr/bin/labplot)
==81335==    by 0x34789D: ??? (in /usr/bin/labplot)
==81335==    by 0x856CCA7: (below main) (libc_start_call_main.h:58)
==81335==  If you believe this happened as a result of a stack
==81335==  overflow in your program's main thread (unlikely but
==81335==  possible), you can try to increase the size of the
==81335==  main thread stack using the --main-stacksize= flag.
==81335==  The main thread stack size used in this run was 8388608.
==81335==
==81335== HEAP SUMMARY:
==81335==     in use at exit: 5,582,866 bytes in 57,547 blocks
==81335==   total heap usage: 274,576 allocs, 217,029 frees,
31,990,582 bytes allocated
==81335==
==81335== LEAK SUMMARY:
==81335==    definitely lost: 5,888 bytes in 20 blocks
==81335==    indirectly lost: 10,748 bytes in 459 blocks
==81335==      possibly lost: 47,667 bytes in 300 blocks
==81335==    still reachable: 5,330,003 bytes in 55,142 blocks
==81335==                       of which reachable via heuristic:
==81335==                         newarray           : 31,288 bytes in
203 blocks
==81335==         suppressed: 0 bytes in 0 blocks
==81335== Rerun with --leak-check=full to see details of leaked memory
==81335==
==81335== Use --track-origins=yes to see where uninitialised values come from
==81335== For lists of detected and suppressed errors, rerun with: -s
==81335== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
fish: Job 1, 'valgrind labplot' terminated by signal SIGSEGV (Address
boundary error)

Dear Maintainer,

LabPlot crashes on startup when the cantor package is not installed.

Steps to reproduce:
  1. Install labplot without cantor installed.
  2. Run: labplot

Actual result:
  LabPlot crashes immediately with SIGSEGV.

Expected result:
  LabPlot should start normally, or disable/hide notebook/CAS integration if Cantor is not installed.

Workaround:
  Installing the cantor package fixes the crash:
  sudo apt install cantor

Backtrace with debug symbols:

Thread 1 "labplot" received signal SIGSEGV, Segmentation fault.
0x00005555557d5584 in MainWin::initGUI(...) at ./src/frontend/MainWin.cpp:291

Relevant source line:
  m_tbNotebook->setDefaultAction(!m_lastUsedNotebookAction ? m_newNotebookMenu->actions().first() : m_lastUsedNotebookAction);

This suggests that m_newNotebookMenu->actions() can be empty, despite the nearby comment saying the menu always contains at least the configure CAS action.

The crash also happened with the official trixie/stable package before I rebuilt 2.12.1 locally, so this is not caused by my local backport.