crash after opening certain images

[dkwo]

Sometimes, if I open 3 or 4 .jpg images in a row, when I close feh with q, lf returns to an empty terminal, using all of my cpu.

What is a way to debug this?

Thanks.

my config:

set shell sh
set shellopts '-eu'
set ifs "\n"
set scrolloff 10
map <enter> shell
map x $$f
map X !$f
map o &mimeopen $f
map O $mimeopen --ask $f

cmd open ${{
    case $(file --mime-type $f -b) in
        text/*) vim $fx;;
        image/vnd.djvu|application/pdf) zathura $fx;;
        image/*) feh $fx;;
        audio/*) mpv $fx;;
        video/*) mpv $fx;;
        *) for f in $fx; do setsid $OPENER $f > /dev/null 2> /dev/null & done;;
    esac
}}

cmd trash %set -f; mv $fx ~/.trash
cmd extract ${{
    set -f
    case $f in
        *.tar.bz|*.tar.bz2|*.tbz|*.tbz2) tar xjvf $f;;
        *.tar.gz|*.tgz) tar xzvf $f;;
        *.tar.xz|*.txz) tar xJvf $f;;
        *.zip) unzip $f;;
        *.rar) unrar x $f;;
        *.7z) 7z x $f;;
    esac
}}
cmd tar ${{
    set -f
    mkdir $1
    cp -r $fx $1
    tar czf $1.tar.gz $1
    rm -rf $1
}}
cmd zip ${{
    set -f
    mkdir $1
    cp -r $fx $1
    zip -r $1.zip $1
    rm -rf $1
}}

[gokcehan]

@dkwo What version are you using and on what platform? Unfortunately, there has been a lot of instability due to ui pausing with shell commands lately which is likely related to your issue. You may try searching previous issues for some solutions and you should also pay attention to the versions in the issues while you are searching as there has been multiple changes lately regarding the terminal handling.

[dkwo]

Version r22, on void linux:

$ lf  --version
r22
$ xuname
Void 5.11.18_1 x86_64-musl GenuineIntel uptodate hold rrnFFFF

[dkwo]

If you think this is not a bug, but a question, could you point me to some other issue where it is solved?
Thanks.

[gokcehan]

@dkwo Sorry, I have a tendency to initially mark things as question and move them to duplicate, bug, or enhancement in time. I still can't reproduce this on my machine but I'm still marking this as a bug so we might get more feedback from others.

There was #592 but it was fixed in r22.

Are you building from source by any chance? If so, can you confirm you are building as a Go module? Tcell upstream changed back to /dev/tty recently but we are still using the old stdin version in our local fork due to #616 . Before, we had #480 when using /dev/tty which might be regressed now again though I think it was MacOS only before.

Also, can you check your log files to see if there is anything related?

[dkwo]

To give more details, it only happens with feh/pictures. I'm using it inside st/tmux, with dwm as window manager.

[dkwo]

I'm using the package from my distro, see
https://github.com/void-linux/void-packages/blob/master/srcpkgs/lf/template
which I believe builds as a go module, see
https://github.com/void-linux/void-packages/blob/master/common/build-style/go.sh

I could build it myself, if any change is needed.

I do not see any logs from lf, is there a specific place to look?

A peculiarity of my system is that it uses runit and musl-libc (instead of glibc), if that matters.

[gokcehan]

@dkwo Thanks for all the details. I'm now able to reproduce the issue myself now. One thing I realized is that it happens much more frequently in bigger images. Before, I was trying it with small images and then it happens rarely in this case, maybe like 1 in 50 or 100.

I have been opening images using xdg-open so far as in the example open command by not setting anything specific for image/* files. I'm not able to reproduce the issue this way, though opening files is a little slower. You can use it as workaround for now. If you want to set xdg-open for images you can add the following to ~/.config/mimeapps.list:

[Default Applications]
image/gif=feh.desktop
image/jpeg=feh.desktop
image/png=feh.desktop

Note, the issue also happens in other applications like mupdf in my case.

Details about log files is in contributing wiki page. In my log files, the only error is the following:

Got EventError: 'read /dev/stdin: resource temporarily unavailable' at 2021-05-14 20:42:24.608444885 +0300 +03 m=+2.789534741

This error happens after each shell command. This has been like so ever since tcell switched from /dev/tty to stdin. So far I was thinking it was a harmless error but maybe it is related. There aren't any common elements in our setups so I still think it's a ui pause issue. I feel like tcell was more stable on linux when it was using /dev/tty but the latest switch to /dev/tty does not work as before and I don't want to switch to tcell upstream before #616 is fixed somehow. Unfortunately I don't know if/when it will happen.

[dkwo]

Thanks for investigating this.
I get the same error, both when it works and when it crashes.
I will try the workaround suggested.

[dkwo]

I'm using the package from my distro, see https://github.com/void-linux/void-packages/blob/master/srcpkgs/lf/template which I believe builds as a go module, see https://github.com/void-linux/void-packages/blob/master/common/build-style/go.sh I could build it myself, if any change is needed. I do not see any logs from lf, is there a specific place to look? A peculiarity of my system is that it uses runit and musl-libc (instead of glibc), if that matters.

[kmarius]

I have also noticed this a few times and I think it happens because the command finishes too quickly after the window is deleted, and while using a tiling wm. I have tested this with mupdf, st, urxvt and feh, all very light programs. Adding some delay to the command stops the crashing, e.g. $st true; sleep 0.005 works fine while $st true reliably crashes. My guess would be that tcell is trying to resize while being re-initialized.

[gokcehan]

I have now switched our tcell to upstream v2.3.1 which uses the /dev/tty interface. Unfortunately, the issue is still there. @kmarius I think you might be right, this might be a racing issue between resize and resume.

[jonsykkel]

im experiencing this also intermittently with sxiv. bug doesnt seem to happen at commit 1b93f22

[gokcehan]

@jonsykkel So then 4c0efdc seems to be the commit we introduced this bug which we bumped our tcell from v2.0.0 to v2.2.0 to use the new suspend/resume API changes.

[mbpowers]

I have solved this issue by implementing the open command found in #384 and setting xdg-open as my $OPENER environment variable. Not familiar with how openers are usually handled especially given that this is cross-platform, but maybe this should be set as the default open command and automatically set the opener variable to the correct value.

[dkwo]

@gokcehan i cannot reproduce this issue after moving to wayland some years ago.
i'm closing this, but feel free to reopen if appropriate. thanks again.