foot crashing #1097

Closed
opened 5 months ago by mizzunet · 23 comments

I've configured river init to start taskwarrior-tui command in foot.

Then on starting river, foot shows up for a second then closes by itself.

No problem on starting taskwarrrior-tui on foot normally.

coredump: https://0x0.st/oSja.txt
that zst file: https://0x0.st/oSjB.zst

I've configured `river` `init` to start `taskwarrior-tui` command in `foot`. Then on starting `river`, `foot` shows up for a second then closes by itself. No problem on starting `taskwarrrior-tui` on `foot` normally. coredump: https://0x0.st/oSja.txt that zst file: https://0x0.st/oSjB.zst
Owner

That backtrace isn't very useful. Can you generate one with a debug build (unstripped) of foot?

That backtrace isn't very useful. Can you generate one with a debug build (unstripped) of foot?
Poster

a debug build (unstripped) of foot

By installing foot from master?

> a debug build (unstripped) of foot By installing foot from master?
Owner

Yes, testing master is better than testing an older version

Yes, testing master is better than testing an older version
Poster
Here: https://0x0.st/oSjx.txt
Owner

That's still from a stripped binary. It needs to be an unstripped debug build.

That's still from a stripped binary. It needs to be an unstripped debug build.
Poster

That's still from a stripped binary. It needs to be an unstripped debug build.

How do I make unstripper debug build. I installed it by foot-git package.

What about this? https://0x0.st/oSjn.txt

> That's still from a stripped binary. It needs to be an unstripped debug build. How do I make unstripper debug build. I installed it by `foot-git` package. What about this? https://0x0.st/oSjn.txt
Owner

Follow the instructions at https://codeberg.org/dnkl/foot/src/branch/master/INSTALL.md#user-content-debug-build. No need to bother with terminfo, or to install. Just run foot from the build directory.

Follow the instructions at https://codeberg.org/dnkl/foot/src/branch/master/INSTALL.md#user-content-debug-build. No need to bother with terminfo, or to install. Just run foot from the build directory.
Poster
Here we go: https://0x0.st/oSec.txt
Owner

Nope, that's still stripped. Looks like the backtrace is still from the system installed foot (/usr/bin/foot), rather than a build local binary.

Nope, that's still stripped. Looks like the backtrace is still from the system installed foot (/usr/bin/foot), rather than a build local binary.
Poster

Right, it's from /usr/bin/foot,

Sat 2022-06-25 23:12:22 IST 955 1000 1000 SIGSEGV present  /usr/bin/foot 502.0K

But I've changed init from foot to /home/missu/de/foot.

I'll try again

Right, it's from /usr/bin/foot, ``` Sat 2022-06-25 23:12:22 IST 955 1000 1000 SIGSEGV present /usr/bin/foot 502.0K ``` But I've changed init from `foot` to `/home/missu/de/foot`. I'll try again
Poster
Finally :D https://0x0.st/oSeA.txt
Owner

Right binary, but still no symbols. Might be the core dump though, and not that the foot binary has been stripped.

If you can reproduce by manually running foot taskwarrior-tui from another terminal, I would recommend trying:

gdb --args /home/missu/de/foot taskwarrior-tui

and then, from the gdb prompt:

run

when foot crashes, run (on the gdb prompt):

bt full
Right binary, but still no symbols. Might be the core dump though, and not that the foot binary has been stripped. If you can reproduce by manually running `foot taskwarrior-tui` from another terminal, I would recommend trying: ```sh gdb --args /home/missu/de/foot taskwarrior-tui ``` and then, from the gdb prompt: ```gdb run ``` when foot crashes, run (on the gdb prompt): ``` bt full ```
Poster

If you can reproduce by manually running foot taskwarrior-tui from another terminal, I would recommend trying:

It doesn't crash then

I hadn't ran bt full earlier.

Here's the one with bt full: https://0x0.st/oSeM.txt

I don't know if it's helpful though

> If you can reproduce by manually running foot taskwarrior-tui from another terminal, I would recommend trying: It doesn't crash then I hadn't ran `bt full` earlier. Here's the one with `bt full`: https://0x0.st/oSeM.txt I don't know if it's helpful though
Owner

I hadn't ran bt full earlier.

That's much better!

#0  0x000055827e4866ff in key_press_release (seat=0x55827f7d0810, term=0x0, serial=17, key=133, state=1) at ../foot/input.c:1377
        __func__ = "key_press_release"
        pressed = true
        released = false
        should_repeat = false
        sym = 65515
        compose_status = XKB_COMPOSE_NOTHING
        composed = false
        mods = 0
        consumed = 0
        locked = 3722747546
        bind_mods = 0
        bind_consumed = 0
        layout_idx = 3287531024
        raw_syms = 0x0
        raw_count = 0
        bindings = 0x7fffc3f3bf98
        count = 32767
        buf = '\000' <repeats 24 times>, "$\254\256\022\225\177\000"
        utf8 = 0x4 <error: Cannot access memory at address 0x4>
        utf32 = 0
        ctx = {layout = 3287531024, key = 32767, sym = 308641847, level0_syms = {syms = 0x55827f7d0810, count = 94018972743536}, mods = 17, consumed = 0, utf8 = {
            buf = 0x1e84 <error: Cannot access memory at address 0x1e84>, count = 125}, utf32 = 1, compose_status = XKB_COMPOSE_NOTHING, 
          key_state = WL_KEYBOARD_KEY_STATE_RELEASED}
        handled = false
#1  0x000055827e48705b in keyboard_key (data=0x55827f7d0810, wl_keyboard=0x55827f78f770, serial=17, time=7812, key=125, state=1) at ../foot/input.c:1575
        seat = 0x55827f7d0810

Looks like river is sending a key release event (maybe the release event for the key binding that launched foot) very early, before foot has everything setup. The term argument is NULL, which is very bad...

> I hadn't ran bt full earlier. That's much better! ```gdb #0 0x000055827e4866ff in key_press_release (seat=0x55827f7d0810, term=0x0, serial=17, key=133, state=1) at ../foot/input.c:1377 __func__ = "key_press_release" pressed = true released = false should_repeat = false sym = 65515 compose_status = XKB_COMPOSE_NOTHING composed = false mods = 0 consumed = 0 locked = 3722747546 bind_mods = 0 bind_consumed = 0 layout_idx = 3287531024 raw_syms = 0x0 raw_count = 0 bindings = 0x7fffc3f3bf98 count = 32767 buf = '\000' <repeats 24 times>, "$\254\256\022\225\177\000" utf8 = 0x4 <error: Cannot access memory at address 0x4> utf32 = 0 ctx = {layout = 3287531024, key = 32767, sym = 308641847, level0_syms = {syms = 0x55827f7d0810, count = 94018972743536}, mods = 17, consumed = 0, utf8 = { buf = 0x1e84 <error: Cannot access memory at address 0x1e84>, count = 125}, utf32 = 1, compose_status = XKB_COMPOSE_NOTHING, key_state = WL_KEYBOARD_KEY_STATE_RELEASED} handled = false #1 0x000055827e48705b in keyboard_key (data=0x55827f7d0810, wl_keyboard=0x55827f78f770, serial=17, time=7812, key=125, state=1) at ../foot/input.c:1575 seat = 0x55827f7d0810 ``` Looks like river is sending a key release event (maybe the release event for the key binding that launched foot) very early, before foot has everything setup. The `term` argument is NULL, which is very bad...
Owner

As far as I can tell, this is a compositor bug; it looks like it's sending a "keyboard key" event on a seat without first having sent a "keyboard enter" event. Either that, or it has sent a "keyboard enter" event, but did so before sending a "keyboard map" event.

In both cases, the seat (in foot) isn't tracking (isn't able to) the currently focused terminal window, and thus it doesn't know where to direct the keyboard event.

At this point, I'm mostly guessing however. It's easy enough to work around in foot, but @ifreund may be interrested in a trace with WAYLAND_DEBUG=1. That'll show exactly which keyboard events, and in which order, the compositor has sent.

You may also want to check if the latest river git version still has this problem (assuming the issue is on the compositor side).

As far as I can tell, this is a compositor bug; it looks like it's sending a _"keyboard key"_ event on a seat without first having sent a _"keyboard enter"_ event. Either that, or it has sent a _"keyboard enter"_ event, but did so **before** sending a _"keyboard map"_ event. In both cases, the seat (in foot) isn't tracking (isn't able to) the currently focused terminal window, and thus it doesn't know where to direct the keyboard event. At this point, I'm mostly guessing however. It's easy enough to work around in foot, but @ifreund may be interrested in a trace with `WAYLAND_DEBUG=1`. That'll show exactly which keyboard events, and in which order, the compositor has sent. You may also want to check if the latest river git version still has this problem (assuming the issue is on the compositor side).
Poster

You may also want to check if the latest river git version still has this problem (assuming the issue is on the compositor side).

river is already the latest master build.

At this point, I'm mostly guessing however. It's easy enough to work around in foot, but @ifreund may be interrested in a trace with WAYLAND_DEBUG=1. That'll show exactly which keyboard events, and in which order, the compositor has sent.

So, I have to start river as WAYLAND_DEBUG=1 river 2> /tmp/river.log, then once foot crashes get the log?

> You may also want to check if the latest river git version still has this problem (assuming the issue is on the compositor side). river is already the latest master build. > At this point, I'm mostly guessing however. It's easy enough to work around in foot, but @ifreund may be interrested in a trace with WAYLAND_DEBUG=1. That'll show exactly which keyboard events, and in which order, the compositor has sent. So, I have to start river as `WAYLAND_DEBUG=1 river 2> /tmp/river.log`, then once foot crashes get the log?
Owner

No, we need a trace from foot, not river.

You'll have to modify your foot binding, to launch a shell that runs foot with WAYLAND_DEBUG=1 and redirects to a file.

No, we need a trace from foot, not river. You'll have to modify your foot binding, to launch a shell that runs foot with WAYLAND_DEBUG=1 and redirects to a file.
Poster

@dnkl here is coredump, foot started with WAYLAND_DEBUG=1 :https://0x0.st/oS9t.txt

@dnkl here is coredump, foot started with WAYLAND_DEBUG=1 :https://0x0.st/oS9t.txt
Owner

We don't need another core dump, but the output from foot, with WAYLAND_DEBUG=1. That is, you need to create a mapping in river, that does something like:

sh -c 'WAYLAND_DEBUG=1 foot &> /tmp/foot.log'
We don't need another core dump, but the output from foot, with `WAYLAND_DEBUG=1`. That is, you need to create a mapping in river, that does something like: ```sh sh -c 'WAYLAND_DEBUG=1 foot &> /tmp/foot.log' ```
Poster

sh -c 'WAYLAND_DEBUG=1 foot &> /tmp/foot.log'

https://0x0.st/oSYb.log

> sh -c 'WAYLAND_DEBUG=1 foot &> /tmp/foot.log' https://0x0.st/oSYb.log
Owner

Thanks! Looks like it sends the "keyboard enter" event before the "keyboard keymap" event.

This is better than not having sent it at all.

Looking at the code, I'm not sure why we ignore the enter event if it arrives before the keymap event. I think this is a bug in foot.

Thanks! Looks like it sends the "keyboard enter" event before the "keyboard keymap" event. This is better than not having sent it at all. Looking at the code, I'm not sure why we ignore the enter event if it arrives before the keymap event. I think this is a bug in foot.
Owner

Can you try #1101?

Can you try https://codeberg.org/dnkl/foot/pulls/1101?
Poster

Can you try #1101?

Seems fixed on it. Not crashing anymore. Thanks (:

> Can you try #1101? Seems fixed on it. Not crashing anymore. Thanks (:
dnkl closed this issue 5 months ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dnkl/foot#1097
Loading…
There is no content yet.