[Bug] Gittyup hangs when staging files, the duration of which is proportionate to the overall size of the staged files.

[RokeJulianLockhart]

Effect Description

It's solely until the file has been staged.

Remediation Suggestion

However, the interface, and stager processes, should be asynchronous (with a loading indicator).

Diagnosis Data

issues/522#issuecomment-2908168432 includes a URI to a perf record. ¹

Footnotes

1. bugzilla.redhat.com/show_bug.cgi?id=2368621#c0 ↩

[Murmele]

I have a large html file and there it works fast if I disable all plugins. Seems they need really long

As a workaround: disabling the plugins

[RokeJulianLockhart]

#522 (comment)

@Murmele, any idea which plugin(s) cause the issue?

[Murmele]

I think all of them together. I looked into them and all of them are iterating over the complete file. So if you have multiple plugins it takes longer

[XeonG]

Is this still an isse on 1.4.0? for large files?

[RokeJulianLockhart]

#522 (comment)

@XeonG, for me, I believe so. I'll try to confirm tomorrow.

[RokeJulianLockhart]

#522 (comment)

@XeonG, it definitely continues:

I tested it by staging Fedora-KDE-Live-x86_64-40-1.14.iso.

[Murmele]

Can you try to disable all plugins?

[RokeJulianLockhart]

#522 (comment)

@Murmele, I only had the trailing whitespace plugin enabled, and disabling that makes no difference.

[XeonG]

yeah it was impossible for me to commit any unstaged files on a new 'git init' project because it just never gave me the chance.. loading or locked up...

I used terminal to commit everything with lfs etc.. and now I can open the repo in gitty 1.4.0 so long as I don't look at one of those past commits.. so unstaged files I can do now.

no plugins enabled in the settings.. well maybe one of them.. but it shouldn't be running on image files etc right

[RokeJulianLockhart]

I've run perf record --call-graph dwarf $HOME/Downloads/Gittyup-1.4.0-x86_64.AppImage (available at mediafire.com/file/zxu5r3oor2x2sf9) whilst staging a 10 GiB file:

1. #!/usr/bin/env sh
   filename=empty.empty
   touch $filename
   fallocate -l 10G $filename

2. qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
   QFont::fromString: Invalid description 'Monospace,10,-1,5,400,0,0,0,0,0,0,0,0,0,0,1'
   QFont::fromString: Invalid description 'Monospace,10,-1,5,400,0,0,0,0,0,0,0,0,0,0,1'
   QFont::fromString: Invalid description 'Monospace,10,-1,5,400,0,0,0,0,0,0,0,0,0,0,1'
   QFont::fromString: Invalid description 'Monospace,10,-1,5,400,0,0,0,0,0,0,0,0,0,0,1'
   qt.glx: qglx_findConfig: Failed to finding matching FBConfig for QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize -1, redBufferSize 1, greenBufferSize 1, blueBufferSize 1, alphaBufferSize -1, stencilBufferSize -1, samples -1, swapBehavior QSurfaceFormat::SingleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile)
   No XVisualInfo for format QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize -1, redBufferSize 1, greenBufferSize 1, blueBufferSize 1, alphaBufferSize -1, stencilBufferSize -1, samples -1, swapBehavior QSurfaceFormat::SingleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile)
   Falling back to using screens root_visual.
   qt.glx: qglx_findConfig: Failed to finding matching FBConfig for QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize -1, redBufferSize 1, greenBufferSize 1, blueBufferSize 1, alphaBufferSize -1, stencilBufferSize -1, samples -1, swapBehavior QSurfaceFormat::SingleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile)
   No XVisualInfo for format QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize -1, redBufferSize 1, greenBufferSize 1, blueBufferSize 1, alphaBufferSize -1, stencilBufferSize -1, samples -1, swapBehavior QSurfaceFormat::SingleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile)
   Falling back to using screens root_visual.
   qt.glx: qglx_findConfig: Failed to finding matching FBConfig for QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize -1, redBufferSize 1, greenBufferSize 1, blueBufferSize 1, alphaBufferSize -1, stencilBufferSize -1, samples -1, swapBehavior QSurfaceFormat::SingleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile)
   No XVisualInfo for format QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize -1, redBufferSize 1, greenBufferSize 1, blueBufferSize 1, alphaBufferSize -1, stencilBufferSize -1, samples -1, swapBehavior QSurfaceFormat::SingleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile)
   Falling back to using screens root_visual.
   [ perf record: Woken up 4052 times to write data ]
   Warning:
   Processed 135016 events and lost 5 chunks!
   
   Check IO/CPU overload!
   
   [ perf record: Captured and wrote 1015.346 MB perf.data (126095 samples) ]

This causes the indexer to crash:

Indexer Crashed - The indexer worker process crashed. If this problem persists please contact us at .

Since this produced no coredump (unlike the Flatpak), I attempted to debug the application, because I wanted to induce it to be killed by the DE whilst hung, and see whether I could debug any child processes that might crash, like the indexer.

However:

1. bugzilla.redhat.com/show_bug.cgi?id=2366461#c21 prevents that in GDB, since the sole workaround I've ascertained (set follow-fork-mode child) attaches to a process that doesn't die when the GUI, etcetera, segmentation faults.

2. gdb -p $PID causes all kinds of breakage.

Even worse, I don't seem to be able to get the AppImage to run in lldb, either! ¹

lldb /home/RokeJulianLockhart/Downloads/Gittyup-1.4.0-x86_64.AppImage
(lldb) target create "/home/RokeJulianLockhart/Downloads/Gittyup-1.4.0-x86_64.AppImage"
Current executable set to '/home/RokeJulianLockhart/Downloads/Gittyup-1.4.0-x86_64.AppImage' (x86_64).
(lldb) run
Process 382819 launched: '/home/RokeJulianLockhart/Downloads/Gittyup-1.4.0-x86_64.AppImage' (x86_64)
Process 382819 stopped and restarted: thread 1 received signal: SIGCHLD
Process 382819 stopped
* thread #1, name = 'AppRun', stop reason = exec
    frame #0: 0x00007ffff7fe3880 ld-linux-x86-64.so.2`_start
ld-linux-x86-64.so.2`_start:
->  0x7ffff7fe3880 <+0>: movq   %rsp, %rdi
    0x7ffff7fe3883 <+3>: callq  0x7ffff7fe4490 ; _dl_start at rtld.c:519:1

ld-linux-x86-64.so.2`_dl_start_user:
    0x7ffff7fe3888 <+0>: movq   %rax, %r12
    0x7ffff7fe388b <+3>: movq   %rsp, %r13
error: ld-linux-x86-64.so.2 0x00031a1f: adding range [0x0000000000000dcb-0x0000000000000dea) which has a base that is less than the function's low PC 0x000000000001d490. Please file a bug and attach the file at the start of this error message
error: ld-linux-x86-64.so.2 0x00031ac0: adding range [0x0000000000000dcb-0x0000000000000dea) which has a base that is less than the function's low PC 0x000000000001d490. Please file a bug and attach the file at the start of this error message
error: ld-linux-x86-64.so.2 0x00031afe: adding range [0x0000000000000dcb-0x0000000000000dea) which has a base that is less than the function's low PC 0x000000000001d490. Please file a bug and attach the file at the start of this error message
error: ld-linux-x86-64.so.2 0x00031b19: adding range [0x0000000000000dcb-0x0000000000000dea) which has a base that is less than the function's low PC 0x000000000001d490. Please file a bug and attach the file at the start of this error message
error: ld-linux-x86-64.so.2 0x00031bd6: adding range [0x0000000000000dcb-0x0000000000000dea) which has a base that is less than the function's low PC 0x000000000001d490. Please file a bug and attach the file at the start of this error message
error: ld-linux-x86-64.so.2 0x00031de9: adding range [0x0000000000000cf2-0x0000000000000dcb) which has a base that is less than the function's low PC 0x000000000001d490. Please file a bug and attach the file at the start of this error message
(lldb) thread backtrace all
* thread #1, name = 'AppRun', stop reason = exec
  * frame #0: 0x00007ffff7fe3880 ld-linux-x86-64.so.2`_start

Details

           PID: 417108 (ld-linux-x86-64)
           UID: 1000 (RokeJulianLockhart)
           GID: 1000 (RokeJulianLockhart)
        Signal: 6 (ABRT)
     Timestamp: Mon 2025-05-26 01:33:47 BST (8h ago)
  Command Line: /tmp/.mount_GittyuJpGhhC/usr/bin/ld-linux-x86-64.so.2 /tmp/.mount_GittyuJpGhhC/usr/bin/gittyup
    Executable: /tmp/.mount_GittyuJpGhhC/usr/bin/ld-linux-x86-64.so.2
 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.ld-linux-x86-64.1000.c6bb945371444d4db4fed95c94da2292.417108.1748219627000000.zst (present)
  Size on Disk: 4.3M
       Message: Process 417108 (ld-linux-x86-64) of user 1000 dumped core.
                
                Module [dso] without build-id.
                Stack trace of thread 417108:
                #0  0x00007f5c29d37361 n/a ([dso] + 0xa24361)
                #1  0x7864806359a457e3 n/a ([dso] + 0x78640107307327e3)
                ELF object binary architecture: AMD x86-64

I'll presume it's due to bugs.llvm.org/show_bug.cgi?id=17972#c0 ² due to the SIGCHLD, but I don't know how to work around it. ³

Luckily, coredumpctl captured a relevant .KCrash from inside the .flatpak:

           PID: 399656 (indexer)
           UID: 1000 (RokeJulianLockhart)
           GID: 1000 (RokeJulianLockhart)
        Signal: 11 (SEGV)
     Timestamp: Mon 2025-05-26 01:01:08 BST (23min ago)
  Command Line: /tmp/.mount_GittyucdENmN/usr/bin/indexer --notify --background /home/RokeJulianLockhart/Documents/UnsanitisedGitRepositories/whale/.git
    Executable: /tmp/.mount_GittyucdENmN/usr/bin/indexer
 Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-dev.warp.Warp@ee92679efb6245b29dffef34fd8f3802.service
          Unit: user@1000.service
     User Unit: app-dev.warp.Warp@ee92679efb6245b29dffef34fd8f3802.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.399656.1748217668000000.zst (present)
  Size on Disk: 307.7K
       Message: Process 399656 (indexer) of user 1000 dumped core.
                
                Stack trace of thread 399656:
                #0  0x0000000000000000 n/a (n/a + 0x0)
                #1  0x00007ffff7fd6bb1 _dl_relocate_object (/usr/lib64/ld-linux-x86-64.so.2 + 0xfbb1)
                #2  0x00007ffff7fe6a43 dl_main (/usr/lib64/ld-linux-x86-64.so.2 + 0x1fa43)
                #3  0x00007ffff7fe32a6 _dl_sysdep_start (/usr/lib64/ld-linux-x86-64.so.2 + 0x1c2a6)
                #4  0x00007ffff7fe4a66 _dl_start_final (/usr/lib64/ld-linux-x86-64.so.2 + 0x1da66)
                #5  0x00007ffff7fe3888 _start (/usr/lib64/ld-linux-x86-64.so.2 + 0x1c888)
                ELF object binary architecture: AMD x86-64

That's from another consistent crash upon cloning https://invent.kde.org/carlschwan/whale, though.

Footnotes

1. discussion.fedoraproject.org/t/154509 ↩

2. stackoverflow.com/revisions/46584839/1 ↩

3. llvm-project/issues/18346#issuecomment-1076515375 ↩