Arch Linux / wayland: bemenu-run -C makes executables list scroll in the menu

[tardypad]

Here is an screencast to better understand what happens:
https://user-images.githubusercontent.com/6368493/236639830-98f206a5-6649-46ab-91fa-789b9f158d42.mp4

I'm quite sure I didn't have this issue when this -C flag was introduced in version 0.6.13 last October. I don't remember when it started to appear but I think it's been several months that I have it.

I'm using Arch Linux, with now sway 1.8.1 and bemenu 0.6.14.
I first tried to remove all customisations to BEMENU_* environment variables, to PATH, to run it on a sway with default config, also using version 0.6.13... but to no avail, the issue was always there.

Now when I tried from a bemenu I've built from scratch (still from the 0.6.14 tarball), the issue disappears.

Looking at the build configuration for Arch I don't see any weird stuff that could explain the behavior I see (no custom patch for example)

I guess the only differences from the official package are then related to the build environment but I'm not sure how to debug this further and what could have resulted in this behavior.

By any chance, have anybody seen this before?
Or do you have any idea what could be the cause?

[Cloudef]

It's a bug in the code,

bemenu/client/common/common.c

Lines 611 to 612 in 8e2fd06

	struct bm_pointer pointer;
	struct bm_touch touch;

these structs are uninitialized

[tardypad]

Then I'm a bit confused about 3 things:

• why I don't see the issue when I compiled it myself with the same bug in the code?
• why I don't have any issue with the -T flag which also makes use of an unitialized struct?
• I'm quite sure I didn't have the issue in last October when this feature was introduced and I was making use of it

[Cloudef]

why I don't see the issue when I compiled it myself with the same bug in the code?

Because uninitialized is the type of bug where the behavior of code will be undefined. The memory state can be anything between runs. You got lucky if the memory state was always that gave you the ideal behavior.

why I don't have any issue with the -T flag which also makes use of an unitialized struct?

Ditto to above

[tardypad]

Ah ok, thanks for the explanations :)