Skip to content

Segfault 28 #352

Open
Open
Segfault 28#352
Assignees
mtwebster

Description

@LinuxOnTheDesktop
LinuxOnTheDesktop
opened on Oct 8, 2024

Describe the bug

From the syslog:

kernel: timeshift[19966]: segfault at 28 ip 000073bbfc0f23fb sp 000073bbf65ff6f0 error 4 in libgobject-2.0.so.0.8000.0[73bbfc0dd000+37000] likely on CPU 8 (core 4, socket 0)

To Reproduce
Unknown. I suspect that Timeshift was running an automated job.

Expected behavior
No segfault reported in the log.

Other information

I have set Timeshift to backup /home, and to put all its backups on a separate partition. (I did this after a crash wiped out stuff beyond recovery.) But I have had segfaults on Timeshift before I adopted that strategy.

On my other Mint PC, and on a now dead PC that ran Mint, System Report never supplied crash dumps. Now, on a new PC, System Report does provide crash dumps - sometimes; there is no dump for this timeshift crash.

I have not seen any adverse behaviour from Timeshift, but possibly a scheduled action was aborted or did not write data properly. Anyhow, segfaults are bad (which is why I have a script to report them to me).

System:

  • Linux Distribution Name and Version: Mint 22
  • Desktop: Cinnamon
  • Application version: 24.06.03
  • Framwork 13 laptop (but, as I say above, I have had segfaults on a variety of hardware)
  • Kernel: 6.8

EDIT: This too appeared in the log:

kernel: snapshot-taker[483769]: segfault at 30 ip 000079dc3f28c61a sp 000079dc333ff780 error 4 in libgobject-2.0.so.0.8000.0[79dc3f277000+37000] likely on CPU 1 (core 0, socket 0)

Activity

  1. LinuxOnTheDesktop commented on Oct 8, 2024

    @LinuxOnTheDesktop
    LinuxOnTheDesktop
    on Oct 8, 2024
    Author

    Please compare #278, which concerns segfaults on restore (obviously: very bad) and contains thorough debugging and an identification of what seems to be the - or at least a - culprit.

  2. burianvlastimil commented on Dec 5, 2024

    @burianvlastimil
    burianvlastimil
    on Dec 5, 2024

    Can I please add also to this or some other thread?:

    I selected 56 snapshots at once, only after 20 I think, I got a segfault, do not really understand it so deep, so this something like a bug report. Thank you in advance for your kind elaboration, if that is an error on Timeshift-GTK side of course. Cheers

    grep NVM /etc/fstab

    UUID=62575d63-cff1-4653-8fce-b8164d24ef93 /mnt/nvm ext4 nofail,nouser,auto,rw,async,x-gvfs-show,x-gvfs-name=NVM 0 0

    timeshift-gtk

    App config loaded: /etc/timeshift/timeshift.json
    Mounted '/dev/nvme0n1p1' at '/run/timeshift/14229/backup'

    Removing '2024-09-03_19-00-01'...
    Removed '2024-09-03_19-00-01'

    Removing '2024-09-04_19-00-01'...
    Removed '2024-09-04_19-00-01'

    Removing '2024-09-05_19-00-02'...
    Removed '2024-09-05_19-00-02'

    Removing '2024-09-06_19-00-01'...
    Removed '2024-09-06_19-00-01'

    Removing '2024-09-07_19-00-01'...
    Removed '2024-09-07_19-00-01'

    Removing '2024-09-08_19-00-01'...
    Removed '2024-09-08_19-00-01'

    Removing '2024-09-09_19-00-01'...
    Removed '2024-09-09_19-00-01'

    Removing '2024-09-10_19-00-01'...
    Removed '2024-09-10_19-00-01'

    Removing '2024-09-11_19-00-01'...
    Removed '2024-09-11_19-00-01'

    Removing '2024-09-12_19-00-01'...
    Removed '2024-09-12_19-00-01'

    Removing '2024-09-13_19-00-02'...
    Removed '2024-09-13_19-00-02'

    Removing '2024-09-14_19-00-01'...
    Removed '2024-09-14_19-00-01'

    Removing '2024-09-16_04-00-01'...
    Removed '2024-09-16_04-00-01'

    Removing '2024-09-17_04-00-01'...
    Removed '2024-09-17_04-00-01'

    Removing '2024-09-18_04-00-01'...
    Removed '2024-09-18_04-00-01'

    Removing '2024-09-19_05-00-01'...
    Removed '2024-09-19_05-00-01'

    Removing '2024-09-20_09-00-01'...
    Removed '2024-09-20_09-00-01'

    Removing '2024-09-21_09-00-01'...
    Removed '2024-09-21_09-00-01'

    Removing '2024-09-22_09-00-02'...
    Removed '2024-09-22_09-00-02'

    Removing '2024-09-23_09-00-01'...
    Segmentation fault (core dumped)ning)

    dmesg # (relevant snippets)

    [Tue Nov 5 12:22:48 2024] delete[15859]: segfault at 28 ip 00007d12e32b23fb sp 00007d12d55ff780 error 4 in libgobject-2.0.so.0.8000.0[7d12e329d000+37000] likely on CPU 4 (core 0, socket 0)
    [Tue Nov 5 12:22:48 2024] Code: 00 83 f8 01 0f 85 55 02 00 00 4c 8d 73 0c 8b 43 0c a8 10 0f 85 e6 00 00 00 48 89 df e8 1e 15 ff ff 48 89 df 49 89 c5 48 8b 03 50 28 8b 43 08 89 45 bc 83 f8 01 0f 8e be 01 00 00 4d 85 ed 0f

    3 core dumps while deleting all snapshots attached below:
    core-dumps.zip

  3. LinuxOnTheDesktop commented on Jan 15, 2025

    @LinuxOnTheDesktop
    LinuxOnTheDesktop
    on Jan 15, 2025
    Author

    I'm still getting periodic segfaults. It's very disconcerting.

  4. LinuxOnTheDesktop commented on Feb 24, 2025

    @LinuxOnTheDesktop
    LinuxOnTheDesktop
    on Feb 24, 2025
    Author

    Just now I had another segfault. System Reports found no stack trace. Here is the system log:

    2025-02-24T00:00:42.111060+00:00 F13 kernel: timeshift[940490]: segfault at 30 ip 000072434ad6261a sp 00007243451ff780 error 4 in libgobject-2.0.so.0.8000.0[72434ad4d000+37000] likely on CPU 3 (core 1, socket 0)

  5. mtwebster
    self-assigned this
    on Aug 27, 2025

  6. woodward2 commented on Sep 25, 2025

    @woodward2
    woodward2
    on Sep 25, 2025

    Also getting sporadic (though becoming more frequent?) segfaults.

    The most recent:

    program output:

    ------------------------------------------------------------------------------
Creating new snapshot...(RSYNC)
Saving to device: /dev/sda2, mounted at path: /run/timeshift/84679/backup
Linking from snapshot: 2025-09-20_08-49-47
Syncing files with rsync...
344.96% complete (00:00:00 remaining)
(process:84679): GLib-GObject-CRITICAL **: 09:27:59.009: g_object_unref: assertion '!object_already_finalized' failed

(process:84679): GLib-GObject-CRITICAL **: 09:27:59.010: instance with invalid (NULL) class pointer

(process:84679): GLib-GObject-CRITICAL **: 09:27:59.010: g_signal_handlers_destroy: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

    from timeshift log:

    andrew $ cat /var/log/timeshift/2025-09-25_09-26-55_ondemand.log 
[09:26:55] Main: check_dependencies()
[09:26:55] Main: add_default_exclude_entries()
[09:26:55] Main: add_default_exclude_entries(): exit
[09:26:55] update_partitions()
[09:26:55] Device: get_disk_space_using_df(): 4
[09:26:55] Device: get_mounted_filesystems_using_mtab(): 4
[09:26:55] Device: get_filesystems(): 19
[09:26:55] partition list updated
[09:26:55] detect_system_devices()
[09:26:55] Searching subvolume for system at path: /
[09:26:55] Users: external andrew root
[09:26:55] Encrypted home users: 
[09:26:55] Encrypted home dirs:

[09:26:55] Encrypted private dirs:

[09:26:55] Main: load_app_config()
[09:26:55] IconManager: init()
[09:26:55] found images directory: /usr/share/timeshift/images
[09:26:55] Main(): ok
[09:26:55] AppConsole: parse_arguments()
[09:26:55] Main: initialize_repo()
[09:26:55] backup_uuid=d83d2c61-c55e-40cc-a722-147c6761d66f
[09:26:55] backup_parent_uuid=
[09:26:55] Setting snapshot device from config file
[09:26:55] repo: creating from uuid
[09:26:55] SnapshotRepo: from_uuid(): RSYNC
[09:26:55] uuid=d83d2c61-c55e-40cc-a722-147c6761d66f
[09:26:55] SnapshotRepo: init_from_device()
[09:26:55] 
[09:26:55] SnapshotRepo: unlock_and_mount_devices()
[09:26:55] device=/dev/sda2
[09:26:55] SnapshotRepo: unlock_and_mount_device()
[09:26:55] device=/dev/sda2
[09:26:55] Device: get_mounted_filesystems_using_mtab(): 4
[09:26:55] ------------------
[09:26:55] arg=d83d2c61-c55e-40cc-a722-147c6761d66f, device=/dev/sda2
[09:26:55] /
[09:26:55] ------------------
[09:26:55] Device: get_mounted_filesystems_using_mtab(): 4
[09:26:55] Mounted '/dev/sda2' at '/run/timeshift/84679/backup'
[09:26:55] SnapshotRepo: load_snapshots()
[09:26:55] loading snapshots from '/run/timeshift/84679/backup/timeshift/snapshots': 10 found
[09:26:55] SnapshotRepo: unlock_and_mount_device(): exit
[09:26:55] Selected snapshot device: /dev/sda2
[09:26:55] Free space: 28.4 GB
[09:26:55] SnapshotRepo: check_status()
[09:26:55] SnapshotRepo: available()
[09:26:55] is_available: ok
[09:26:55] SnapshotRepo: has_snapshots()
[09:26:55] SnapshotRepo: has_space() - 0 required (0 B)
[09:26:55] Device: get_disk_space_using_df(): 1
[09:26:55] SnapshotRepo: check_status(): exit
[09:26:55] SnapshotRepo: init_from_device(): exit
[09:26:55] SnapshotRepo: from_uuid(): exit
[09:26:55] Main: initialize_repo(): exit
[09:26:55] AppConsole: start_application()
[09:26:55] Main: create_snapshot()
[09:26:55] SnapshotRepo: has_space() - 0 required (0 B)
[09:26:55] Device: get_disk_space_using_df(): 1
[09:26:55] Main: backup_and_rotate()
[09:26:55] SnapshotRepo: available()
[09:26:55] is_available: ok
[09:26:55] ------------------------------------------------------------------------------
[09:26:55] Creating new snapshot...(RSYNC)
[09:26:55] Saving to device: /dev/sda2, mounted at path: /run/timeshift/84679/backup
[09:26:55] Linking from snapshot: 2025-09-20_08-49-47
[09:26:55] Main: save_exclude_list_for_backup()
[09:26:55] Main: create_exclude_list_for_backup()
[09:26:55] Main: create_exclude_list_for_backup(): exit
[09:26:55] Syncing files with rsync...
[09:26:55] RsyncTask:execute()
[09:26:55] export LC_ALL=C.UTF-8
rsync -aii --recursive --verbose --delete --force --stats --sparse --delete-excluded --link-dest='/run/timeshift/84679/backup/timeshift/snapshots/2025-09-20_08-49-47/localhost/' --log-file='/run/timeshift/84679/backup/timeshift/snapshots/2025-09-25_09-26-55/rsync-log' --exclude-from='/run/timeshift/84679/backup/timeshift/snapshots/2025-09-25_09-26-55/exclude.list' --delete-excluded '/' '/run/timeshift/84679/backup/timeshift/snapshots/2025-09-25_09-26-55/localhost/'
[09:26:55] RsyncTask:prepare(): saved: /tmp/jFhwTuLm/2025-09-25_09-26-55/script.sh
[09:26:55] AsyncTask: child_pid: 84708
[09:27:59] AsyncTask: finish(): enter
[09:27:59] exit_code: 0

    from syslog:

    2025-09-25T09:27:59.010589+01:00 nuc-server kernel: timeshift[84713]: segfault at 30 ip 0000727634f1e61a sp 000072762fbfd780 error 4 in libgobject-2.0.so.0.8000.0[727634f09000+37000] likely on CPU 3 (core 1, socket 0)
2025-09-25T09:27:59.010609+01:00 nuc-server kernel: Code: 31 d2 4c 89 e7 e8 36 b3 fe ff 48 89 df e8 3e fc 00 00 8b 35 f0 da 03 00 31 c9 31 d2 4c 89 e7 e8 1c b3 fe ff 48 8b 03 48 89 df <ff> 50 30 48 89 df e8 db 57 01 00 e9 7e fe ff ff 66 0f 1f 44 00 00

    System:
    OS: Ubuntu Server 24.04.3 LTS
    Kernel: 6.8.0-84-generic
    Timeshift: 24.01.1

  7. ygerlach commented on Sep 26, 2025

    @ygerlach
    ygerlach
    on Sep 26, 2025
    Contributor

    If you have systemd-coredump installed, it may have saved the crash dump.
    You can list all known crashes with sudo coredumpctl list and get more details with sudo coredumpctl info <pid> or sudo coredumpctl debug <pid>.
    Feel free to upload the core file from /var/lib/systemd/coredump or a log from a gdb session with thread apply all bt full

  8. woodward2 commented on Sep 27, 2025

    @woodward2
    woodward2
    on Sep 27, 2025

    systemd-coredump wasn't installed on my Ubuntu Server 24, but I have now installed it.

    It is installed on my desktop & HTPC (both Linux Mint 21.3 with timeshift 24.01.1) and my workshop PC (Linux Mint 22.2 with timeshift 25.07.7), but they don't have any recent timeshift crashes.

    Will monitor and await developments...

  9. woodward2 commented on Dec 20, 2025

    @woodward2
    woodward2
    on Dec 20, 2025

    Crashed this morning:

    andrew $ sudo coredumpctl debug 826772
           PID: 826772 (timeshift)
           UID: 0 (root)
           GID: 0 (root)
        Signal: 11 (SEGV)
     Timestamp: Sat 2025-12-20 07:45:19 GMT (31min ago)
  Command Line: /usr/bin/timeshift --create --comments $'Critical update: systemd'
    Executable: /usr/bin/timeshift
 Control Group: /user.slice/user-1000.slice/session-5495.scope
          Unit: session-5495.scope
         Slice: user-1000.slice
       Session: 5495
     Owner UID: 1000 (andrew)
       Boot ID: deb7cb7f9caf4e03a889bb7ff558523f
    Machine ID: 4e8ceaa793184564b9ebb488a6205622
      Hostname: nuc-server.woodwards.com
       Storage: /var/lib/systemd/coredump/core.timeshift.0.deb7cb7f9caf4e03a889bb7ff558523f.826772.1766216719000000.zst (present)
  Size on Disk: 592.3K
       Message: Process 826772 (timeshift) of user 0 dumped core.
                
                Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2build1.1.amd64
                Module libgcc_s.so.1 from deb gcc-14-14.2.0-4ubuntu2~24.04.amd64
                Module libstdc++.so.6 from deb gcc-14-14.2.0-4ubuntu2~24.04.amd64
                Module libsystemd.so.0 from deb systemd-255.4-1ubuntu8.11.amd64
                Stack trace of thread 826807:
                #0  0x00007035a2dee61a g_object_unref (libgobject-2.0.so.0 + 0x2461a)
                #1  0x000061e1db724265 n/a (timeshift + 0x2b265)
                #2  0x000061e1db724a85 n/a (timeshift + 0x2ba85)
                #3  0x00007035a2eb8d92 n/a (libglib-2.0.so.0 + 0x8bd92)
                #4  0x00007035a1e9caa4 n/a (libc.so.6 + 0x9caa4)
                #5  0x00007035a1f29c6c n/a (libc.so.6 + 0x129c6c)
                
                Stack trace of thread 826772:
                #0  0x00007035a1eecadf clock_nanosleep (libc.so.6 + 0xecadf)
                #1  0x00007035a1ef9a27 __nanosleep (libc.so.6 + 0xf9a27)
                #2  0x00007035a2eba6be g_usleep (libglib-2.0.so.0 + 0x8d6be)
                #3  0x000061e1db71117a n/a (timeshift + 0x1817a)
                #4  0x000061e1db711c75 n/a (timeshift + 0x18c75)
                #5  0x000061e1db706e36 n/a (timeshift + 0xde36)
                #6  0x000061e1db703674 n/a (timeshift + 0xa674)
                #7  0x00007035a1e2a1ca n/a (libc.so.6 + 0x2a1ca)
                #8  0x00007035a1e2a28b __libc_start_main (libc.so.6 + 0x2a28b)
                #9  0x000061e1db704f75 n/a (timeshift + 0xbf75)
                
                Stack trace of thread 826796:
                #0  0x00007035a1f1b4fd __poll (libc.so.6 + 0x11b4fd)
                #1  0x00007035a2ee968e n/a (libglib-2.0.so.0 + 0xbc68e)
                #2  0x00007035a2e89a63 g_main_context_iteration (libglib-2.0.so.0 + 0x5ca63)
                #3  0x00007035a2e89ab9 n/a (libglib-2.0.so.0 + 0x5cab9)
                #4  0x00007035a2eb8d92 n/a (libglib-2.0.so.0 + 0x8bd92)
                #5  0x00007035a1e9caa4 n/a (libc.so.6 + 0x9caa4)
                #6  0x00007035a1f29c6c n/a (libc.so.6 + 0x129c6c)
                
                Stack trace of thread 826806:
                #0  0x00007035a1f1b215 __open64 (libc.so.6 + 0x11b215)
                #1  0x00007035a2379dde n/a (libgio-2.0.so.0 + 0x149dde)
                #2  0x000061e1db731092 n/a (timeshift + 0x38092)
                #3  0x000061e1db7311ec n/a (timeshift + 0x381ec)
                #4  0x000061e1db72442f n/a (timeshift + 0x2b42f)
                #5  0x000061e1db7247a9 n/a (timeshift + 0x2b7a9)
                #6  0x00007035a2eb8d92 n/a (libglib-2.0.so.0 + 0x8bd92)
                #7  0x00007035a1e9caa4 n/a (libc.so.6 + 0x9caa4)
                #8  0x00007035a1f29c6c n/a (libc.so.6 + 0x129c6c)
                ELF object binary architecture: AMD x86-64

Failed to invoke gdb: No such file or directory

    Tried to upload the core file ... "File type .zst not supported"

  10. ygerlach commented on Dec 20, 2025

    @ygerlach
    ygerlach
    on Dec 20, 2025
    Contributor

    Tried to upload the core file ... "File type .zst not supported"

    try uploading it elsewhere and share the link here.

  11. woodward2 commented on Dec 20, 2025

    @woodward2
    woodward2
    on Dec 20, 2025

    Link to core dump: https://limewire.com/d/qDn7T#DyTTT0KGoD

  12. woodward2 commented on Jan 6, 2026

    @woodward2
    woodward2
    on Jan 6, 2026

    Failed again this morning (slightly different error):

    ------------------------------------------------------------------------------
Creating new snapshot...(RSYNC)
Saving to device: /dev/sda2, mounted at path: /run/timeshift/1868453/backup
Linking from snapshot: 2026-01-05_04-00-01
Syncing files with rsync...
270.52% complete (00:00:00 remaining)
(process:1868453): GLib-GObject-CRITICAL **: 09:21:38.693: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(process:1868453): GLib-GObject-CRITICAL **: 09:21:38.693: instance with invalid (NULL) class pointer

(process:1868453): GLib-GObject-CRITICAL **: 09:21:38.693: g_signal_handlers_destroy: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

    andrew $ sudo coredumpctl debug 1868453
           PID: 1868453 (timeshift)
           UID: 0 (root)
           GID: 0 (root)
        Signal: 11 (SEGV)
     Timestamp: Tue 2026-01-06 09:21:38 GMT (5min ago)
  Command Line: /usr/bin/timeshift --create --comments $'Critical update: firmware'
    Executable: /usr/bin/timeshift
 Control Group: /user.slice/user-1000.slice/session-11692.scope
          Unit: session-11692.scope
         Slice: user-1000.slice
       Session: 11692
     Owner UID: 1000 (andrew)
       Boot ID: 1dc856d31a784d028c7ca3cd47d53752
    Machine ID: 4e8ceaa793184564b9ebb488a6205622
      Hostname: nuc-server.woodwards.com
       Storage: /var/lib/systemd/coredump/core.timeshift.0.1dc856d31a784d028c7ca3cd47d53752.1868453.1767691298000000.zst (present)
  Size on Disk: 588.0K
       Message: Process 1868453 (timeshift) of user 0 dumped core.
                
                Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2build1.1.amd64
                Module libgcc_s.so.1 from deb gcc-14-14.2.0-4ubuntu2~24.04.amd64
                Module libstdc++.so.6 from deb gcc-14-14.2.0-4ubuntu2~24.04.amd64
                Module libsystemd.so.0 from deb systemd-255.4-1ubuntu8.12.amd64
                Stack trace of thread 1868488:
                #0  0x000075251185561a g_object_unref (libgobject-2.0.so.0 + 0x2461a)
                #1  0x000063d134056265 n/a (timeshift + 0x2b265)
                #2  0x000063d134056a85 n/a (timeshift + 0x2ba85)
                #3  0x000075251191fd92 n/a (libglib-2.0.so.0 + 0x8bd92)
                #4  0x000075251089caa4 n/a (libc.so.6 + 0x9caa4)
                #5  0x0000752510929c6c n/a (libc.so.6 + 0x129c6c)
                
                Stack trace of thread 1868487:
                #0  0x0000752511857b8d n/a (libgobject-2.0.so.0 + 0x26b8d)
                #1  0x0000752511859bc3 g_object_new_valist (libgobject-2.0.so.0 + 0x28bc3)
                #2  0x0000752511859f4f g_object_new (libgobject-2.0.so.0 + 0x28f4f)
                #3  0x000063d1340630ab n/a (timeshift + 0x380ab)
                #4  0x000063d1340631ec n/a (timeshift + 0x381ec)
                #5  0x000063d13405642f n/a (timeshift + 0x2b42f)
                #6  0x000063d1340567a9 n/a (timeshift + 0x2b7a9)
                #7  0x000075251191fd92 n/a (libglib-2.0.so.0 + 0x8bd92)
                #8  0x000075251089caa4 n/a (libc.so.6 + 0x9caa4)
                #9  0x0000752510929c6c n/a (libc.so.6 + 0x129c6c)
                
                Stack trace of thread 1868453:
                #0  0x00007525108ecadf clock_nanosleep (libc.so.6 + 0xecadf)
                #1  0x00007525108f9a27 __nanosleep (libc.so.6 + 0xf9a27)
                #2  0x00007525119216be g_usleep (libglib-2.0.so.0 + 0x8d6be)
                #3  0x000063d13404317a n/a (timeshift + 0x1817a)
                #4  0x000063d134043c75 n/a (timeshift + 0x18c75)
                #5  0x000063d134038e36 n/a (timeshift + 0xde36)
                #6  0x000063d134035674 n/a (timeshift + 0xa674)
                #7  0x000075251082a1ca n/a (libc.so.6 + 0x2a1ca)
                #8  0x000075251082a28b __libc_start_main (libc.so.6 + 0x2a28b)
                #9  0x000063d134036f75 n/a (timeshift + 0xbf75)
                
                Stack trace of thread 1868477:
                #0  0x000075251091b4fd __poll (libc.so.6 + 0x11b4fd)
                #1  0x000075251195068e n/a (libglib-2.0.so.0 + 0xbc68e)
                #2  0x00007525118f0a63 g_main_context_iteration (libglib-2.0.so.0 + 0x5ca63)
                #3  0x00007525118f0ab9 n/a (libglib-2.0.so.0 + 0x5cab9)
                #4  0x000075251191fd92 n/a (libglib-2.0.so.0 + 0x8bd92)
                #5  0x000075251089caa4 n/a (libc.so.6 + 0x9caa4)
                #6  0x0000752510929c6c n/a (libc.so.6 + 0x129c6c)
                ELF object binary architecture: AMD x86-64

Failed to invoke gdb: No such file or directory

    Link to core dump: https://limewire.com/d/7oidm#qAaLkTM2ME

  13. bubbaprog commented on Apr 3, 2026

    @bubbaprog
    bubbaprog
    on Apr 3, 2026

    Just hopping in here to note that I discovered this was happening every time Timeshift ran and in fact a complete backup (which I have set to run daily) hasn't completed in two weeks, so this segfault can happen in a way that's not even immediately obvious.

  14. mkilicar commented on Sep 23, 2026

    @mkilicar
    mkilicar
    on Sep 23, 2026

    Same crash on Ubuntu 24.04, Timeshift 24.01.1 (24.01.1-1build2), GLib 2.80, hourly cron timeshift --check --scripted on a 40-thread machine. About 4 crashes in 4 days, always ~37 s after the backup disk is mounted, i.e. during the snapshot's rsync. Kernel: segfault at 30 … in libgobject-2.0.so.0.8000.0[2461a,…], i.e. call *0x30(%rax) (finalize) in g_object_unref on an already-freed object.

    Backtrace from the apport core (no symbols): crashed thread = g_object_unref ← timeshift+0x2b210 ← timeshift+0x2ba85 ← GLib thread wrapper. Disassembly of the stripped binary (my reading, unverified against source): +0x2b160 is AsyncTask.finish() (it logs "AsyncTask: finish(): enter"). It checks a flag at priv+0x3c, sets it with a plain store, then does if (stream != NULL) { g_object_unref(stream); stream = NULL; } on an output stream, with no lock. It's called from the end of the stdout/stderr reader-thread function when both "open" flags are 0. A second thread had a frame inside the same function (+0x2b42f, in g_file_query_exists) when the core was taken. Likely both reader threads finish together when rsync closes its pipes, both call finish(), and the stream is unref'd twice.

    make the finish_called test-and-set atomic (mutex, or an atomic compare-and-swap), and don't NULL the stream pointer after unref outside that guard.

  15. Arcaudas commented on Oct 15, 2026

    @Arcaudas
    Arcaudas
    on Oct 15, 2026

    Same crash here, on a newer Timeshift and GLib than the reports above.

    Environment

    • Timeshift 24.06.6 (24.06.6+faye package), Debian 13 (trixie), kernel 6.12.107+deb13-amd64
    • GLib 2.84.4 (libglib2.0-0t64 2.84.4-3~deb13u5)
    • RSYNC mode, hourly cron timeshift --check --scripted, 16 logical CPUs

    What happens
    It crashed twice on the same day (12:21 and 16:13). The runs in between and after completed normally. Both times the rsync had finished with exit_code: 0, and the process segfaulted in the same second:

    [12:21:03] AsyncTask: finish(): enter
[12:21:03] exit_code: 0

    kernel: async-task-stde[251865]: segfault at 30 ip 00007fd595b2b4fb sp 00007fd58b7fd750 error 4 in libgobject-2.0.so.0.8400.4[1d4fb,7fd595b1e000+35000]
kernel: async-task-stdo[534144]: segfault at 30 ip 00007f20c69d04fb sp 00007f20c11fd760 error 4 in libgobject-2.0.so.0.8400.4[1d4fb,7f20c69c3000+35000]

    The crashing thread differs between the two crashes: the stderr reader the first time (async-task-stde) and the stdout reader the second time (async-task-stdo). The offset in libgobject is identical (1d4fb). This fits the analysis by @mkilicar: both reader threads reach finish() at the same time.

    The snapshot directory is left without info.json, so that hour's snapshot is lost and the backup device stays mounted under /run/timeshift/<pid>/backup until the next run.

    Current master
    The guard at the top of finish() in src/Utility/AsyncTask.vala is still a plain check-then-set with no lock:

    if (finish_called) { return; }
finish_called = true;

    Both threads can pass that check before either one sets the flag. As far as I can tell, the race is still present in 26.09.0. An atomic compare-and-swap, or doing the check and the set under a mutex, should be enough to make finish() run only once.

    I have the two systemd-coredump cores. I can run coredumpctl debug / thread apply all bt on them if that helps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions