[BUG][CRASH] about kakoune HOT 13 OPEN

looks like you spawn an awk process that eats up all memory. I assume no other process uses a signifcant amount of memory.
How do you start that awk process? I can't find Convert a position a document to a position in our list of flags anywhere.
Can you give a small reproducer?

from kakoune.

I'm not sure how to reproduce exactly. Maybe it is specific to my config, but I have disabled major plugins like kak-lsp before test. Also this is not happening with release with same config.

from kakoune.

To fix this we need to find out who is using all the 22GB of memory. The awk command and its stdin might be enough.

So you're saying the OOM does not happen on the release? Or only the coredump?

from kakoune.

So you're saying the OOM does not happen on the release? Or only the coredump?

Exactly, with release version of kakoune I don't have both.

from kakoune.

Ok, I found culprit plugin.

from kakoune.

does it reproduce consistently?
If yes, it shouldn't take long to run a git bisect.
There are only 28 commits in git log v2023.08.05..origin/master src
On Linux, you could limit the amount of memory using cgroups to prevent a general system freeze. Also disable swap for reproducing this.

from kakoune.

OOM and crash not happening with disabled scrollbar.kak plugin. But surprisingly it works in release version.

from kakoune.

ok the easiest approach might be to add print statements to every loop in the awk process. It's only 4 loops.

I suspect that in

for (i=flags_start; i<=flags_end; i++) {
    flags_by_line[i] = 1
}

flags_start > flags_end so we loop for billions of times.
This could be the case if %val{window_range} is reported differently for new clients.
Maybe 9787756 (Use last display setup instead of recomputing for window_range, 2023-09-08).

from kakoune.

I invoke scrollbar-enable at WinCreate hook, like:

hook global WinCreate .* %{
    scrollbar-enable
}

With this hook disabled, invoking at prompt new; scrollbar-enable works as expected, i.e. not causing OOM and crash.

from kakoune.

ok the easiest approach might be to add print statements to every loop in the awk process. It's only 4 loops.

I suspect that in

for (i=flags_start; i<=flags_end; i++) {
    flags_by_line[i] = 1
}

flags_start > flags_end so we loop for billions of times. This could be the case if %val{window_range} is reported differently for new clients. Maybe 9787756 (Use last display setup instead of recomputing for window_range, 2023-09-08).

I managed to print flats_start and flags_end values right before the loop, so flags_end ends up having enormous big values:

flags_start: 0
flags_end: 360284
flags_start: 0
flags_end: 348847
flags_start: 0
flags_end: 338113

from kakoune.

I can reproduce with

timeout -sKILL 5 src/kak -e 'source ../scrollbar.kak/scrollbar.kak; hook g WinCreate .* scrollbar-enable; new; new; new; new'; reset

the clients that don't manage to show the scratch buffer triggered the bug.
Bisects to 9787756 (Use last display setup instead of recomputing for window_range, 2023-09-08).
Haven't root-caused it yet. window_range appears to be zero even in the affected clients.
Maybe it's some kind of UB causing kakoune to run into a loop or something

from kakoune.

Yeah, I reported this as #4975 and then tried to update the documentation in #4994. Unfortunately it seems I still don't quite understand how things should work, so I haven't been able to fix the docs properly or fix the scrollbar plugin.

from kakoune.

right I forgot to run with sanitizers

from kakoune.