If, in bash, I invoke lldb --wait-for /var/lib/flatpak/app/com.github.Murmele.Gittyup/x86_64/stable/adfe463ee26a63bdaaa0af13f71e26bf9a925d37f43b4527c7b14625ab5a08a7/files/bin/gittyup, then, in another bash instance, invoke /var/lib/flatpak/app/com.github.Murmele.Gittyup/x86_64/stable/adfe463ee26a63bdaaa0af13f71e26bf9a925d37f43b4527c7b14625ab5a08a7/files/bin/gittyup, lldb doesn’t attach. Am I missing a step?
Context
I’m attempting to capture a coredump of /var/lib/flatpak/app/com.github.Murmele.Gittyup/x86_64/stable/adfe463ee26a63bdaaa0af13f71e26bf9a925d37f43b4527c7b14625ab5a08a7/files/bin/indexer, which is spawned by ./gittyup, to later be evaluated inside flatpak run --command=sh --devel com.github.Murmele.Gittyup, with gdb (because that’s all that is available there):
opened 12:43AM - 26 May 25 UTC
#### Evidence
Choosing one of the many available:
<blockquote>
~~~MA
Sun 2025… -05-25 23:24:45 BST 342056 1000 1000 SIGABRT present /app/bin/indexer 756.2K
Mon 2025-05-26 00:14:53 BST 373268 1000 1000 SIGSEGV present /tmp/.mount_GittyuafkIff/usr/bin/indexer 307.7K
Mon 2025-05-26 00:14:53 BST 373281 1000 1000 SIGSEGV present /tmp/.mount_GittyuafkIff/usr/bin/indexer 308.6K
Mon 2025-05-26 00:14:54 BST 373356 1000 1000 SIGSEGV present /tmp/.mount_GittyuafkIff/usr/bin/indexer 307.9K
Mon 2025-05-26 00:14:57 BST 373430 1000 1000 SIGSEGV present /tmp/.mount_GittyuafkIff/usr/bin/indexer 308K
Mon 2025-05-26 00:17:05 BST 374856 1000 1000 SIGSEGV present /tmp/.mount_GittyuAGoamg/usr/bin/indexer 308.2K
Mon 2025-05-26 00:17:39 BST 375198 1000 1000 SIGSEGV present /tmp/.mount_GittyuAGoamg/usr/bin/indexer 308.7K
Mon 2025-05-26 00:57:59 BST 397494 1000 1000 SIGSEGV present /tmp/.mount_GittyumDHDoE/usr/bin/indexer 308.1K
Mon 2025-05-26 00:57:59 BST 397511 1000 1000 SIGSEGV present /tmp/.mount_GittyumDHDoE/usr/bin/indexer 307K
Mon 2025-05-26 01:00:57 BST 399344 1000 1000 SIGSEGV present /tmp/.mount_GittyucdENmN/usr/bin/indexer 307.7K
Mon 2025-05-26 01:00:57 BST 399357 1000 1000 SIGSEGV present /tmp/.mount_GittyucdENmN/usr/bin/indexer 307.7K
Mon 2025-05-26 01:01:08 BST 399656 1000 1000 SIGSEGV present /tmp/.mount_GittyucdENmN/usr/bin/indexer 307.7K
~~~
</blockquote>
...I see:
<blockquote>
~~~YAML
PID: 417516 (indexer)
UID: 1000 (RokeJulianLockhart)
GID: 1000 (RokeJulianLockhart)
Signal: 11 (SEGV)
Timestamp: Mon 2025-05-26 01:33:35 BST (9min ago)
Command Line: /tmp/.mount_GittyuJpGhhC/usr/bin/indexer --notify --background /home/RokeJulianLockhart/Documents/UnsanitisedGitRepositories/whale/.git
Executable: /tmp/.mount_GittyuJpGhhC/usr/bin/indexer
Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-dev.warp.Warp@1fbad6fb2dd14b94931642cd96af43ae.service
Unit: user@1000.service
User Unit: app-dev.warp.Warp@1fbad6fb2dd14b94931642cd96af43ae.service
Slice: user-1000.slice
Owner UID: 1000 (RokeJulianLockhart)
Boot ID: c6bb945371444d4db4fed95c94da2292
Machine ID: b4f0bef5ffd640fba0ab31fdaa2820b8
Hostname: Beedell.RokeJulianLockhart.desktop.SSV2AY
Storage: /var/lib/systemd/coredump/core.indexer.1000.c6bb945371444d4db4fed95c94da2292.417516.1748219615000000.zst (present)
Size on Disk: 307.3K
Message: Process 417516 (indexer) of user 1000 dumped core.
Stack trace of thread 417516:
#0 0x0000000000000000 n/a (n/a + 0x0)
#1 0x00007f6f6a3b6bb1 _dl_relocate_object (/usr/lib64/ld-linux-x86-64.so.2 + 0xfbb1)
#2 0x00007f6f6a3c6a43 dl_main (/usr/lib64/ld-linux-x86-64.so.2 + 0x1fa43)
#3 0x00007f6f6a3c32a6 _dl_sysdep_start (/usr/lib64/ld-linux-x86-64.so.2 + 0x1c2a6)
#4 0x00007f6f6a3c4a66 _dl_start_final (/usr/lib64/ld-linux-x86-64.so.2 + 0x1da66)
#5 0x00007f6f6a3c3888 _start (/usr/lib64/ld-linux-x86-64.so.2 + 0x1c888)
ELF object binary architecture: AMD x86-64
~~~
</blockquote>
However, did you notice the sole exception (`/app/bin/indexer`)? It differs significantly:
<blockquote>
~~~YAML
PID: 342056 (indexer)
UID: 1000 (RokeJulianLockhart)
GID: 1000 (RokeJulianLockhart)
Signal: 6 (ABRT)
Timestamp: Sun 2025-05-25 23:24:45 BST (2h 21min ago)
Command Line: /app/bin/indexer --notify --background /home/RokeJulianLockhart/Documents/UnsanitisedGitRepositories/whale/.git
Executable: /app/bin/indexer
Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-flatpak-com.github.Murmele.Gittyup-3658868694.scope
Unit: user@1000.service
User Unit: app-flatpak-com.github.Murmele.Gittyup-3658868694.scope
Slice: user-1000.slice
Owner UID: 1000 (RokeJulianLockhart)
Boot ID: c6bb945371444d4db4fed95c94da2292
Machine ID: b4f0bef5ffd640fba0ab31fdaa2820b8
Hostname: Beedell.RokeJulianLockhart.desktop.SSV2AY
Storage: /var/lib/systemd/coredump/core.indexer.1000.c6bb945371444d4db4fed95c94da2292.342056.1748211885000000.zst (present)
Size on Disk: 756.2K
Message: Process 342056 (indexer) of user 1000 dumped core.
Stack trace of thread 344:
#0 0x00007f36ebaa3eb4 n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x90eb4)
#1 0x00007f36eba51dce n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x3edce)
#2 0x00007f36eba3983f n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x2683f)
#3 0x00007f36ebcc1f0a n/a (/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.32 + 0xc1f0a)
#4 0x00007f36ebcbfbfa n/a (/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.32 + 0xbfbfa)
#5 0x00007f36ebcbfc65 n/a (/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.32 + 0xbfc65)
#6 0x00007f36ebcc0a53 n/a (/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.32 + 0xc0a53)
#7 0x00007f36ec15e536 n/a (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.10 + 0x15e536)
#8 0x00007f36ec1cbc5a n/a (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.10 + 0x1cbc5a)
#9 0x00007f36ec1bf30f n/a (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.10 + 0x1bf30f)
#10 0xcb735c8ad0204d00 n/a (n/a + 0x0)
ELF object binary architecture: AMD x86-64
~~~
</blockquote>
I'll attempt to attach a screencast, too.
#### Context
First discovered during diagnosis of https://github.com/Murmele/Gittyup/issues/522#issuecomment-2908168432.
#### Environment
<blockquote>
~~~YAML
ID: com.github.Murmele.Gittyup
Ref: app/com.github.Murmele.Gittyup/x86_64/stable
Arch: x86_64
Branch: stable
Version: v1.4.0
License: MIT
Origin: flathub
Collection: org.flathub.Stable
Installation: system
Installed: 72.4 MB
Runtime: org.kde.Platform/x86_64/5.15-23.08
Sdk: org.kde.Sdk/x86_64/5.15-23.08
Commit: adfe463ee26a63bdaaa0af13f71e26bf9a925d37f43b4527c7b14625ab5a08a7
Parent: 7e1c9370a1a462478b7fac34aac11882cb62768886aa23fe4fd36fb23c17e19b
Subject: update to release 1.4.0 (#44) (21f22a60)
Date: 2024-05-15 22:15:19 +0000
~~~
</blockquote>
Environment
lldb-20.1.5-1.fc42.x86_64:
Name : lldb
Epoch : 0
Version : 20.1.5
Release : 1.fc42
Architecture : x86_64
Installed size : 25.4 MiB
Source : llvm-20.1.5-1.fc42.src.rpm
From repository : <unknown>
URL : http://lldb.llvm.org/
Vendor : Fedora Project
try lldb --wait-for -n /your/process
We should probably make --wait-for without the name argument return an error..
1 Like
@labath , thank you! That worked:
Until flatpak permits anything but gdb for debugging inside the sandbox:
…I’m forced to utilise gdb if I want symbols:
Consequently, can I run lldb --wait-for -n /var/lib/flatpak/app/$identifier/$architecture/stable/$commit/files/bin/$binary on the host, then choose a --style for process save-core $path that’s compatible with gdb? I ask because I’m not confident that even installing the relevant software outside the sandbox would be of much use without DebugInfoD support:
@JDevlieghere , thanks for the attribution.