A KTS thread gets stuck sometimes

[hadronized]

More investigating is needed (maybe it’s what causing #156; maybe not). Basically, sometimes, a buffer stop getting highlighted (and the session freezes). Killing the session and opening a new one get no highlighting, even though KTS responds.

[hadronized]

Hm, given the result I get, I “think” it can be a stuck Kakoune because the ranges-spec is too big?

[hadronized]

Killing the Kakoune session and starting it from another side works, so this doesn’t relate to #156. However, it gives us the answer I was looking for: the problem is on the Kakoune side; we probably send too much data? Maybe there’s a limit on the size of data we can pass when doing a set-option? I need to be sure before opining a Kakoune bug report.

[hadronized]

The length is 268513, which maybe causes Kakoune option to freak out?

On the Kakoune side:

frame #4: 0x00000001027be24f kak`main(argc=3, argv=0x00007ff7bdaa20e0) at main.cc:1152:20
   1149                     return -1;
   1150                 }
   1151             }
-> 1152             return run_pipe(*session);

frame #3: 0x00000001027bc0d1 kak`Kakoune::run_pipe(session=StringView @ 0x00007ff7bda9fb88) at main.cc:1017:9
   1014 {
   1015     try
   1016     {
-> 1017         send_command(session, read_fd(0));

frame #2: 0x000000010298287f kak`Kakoune::send_command(session=StringView @ 0x00007ff7bda9fa90, command=StringView @ 0x00007ff7bd
a9fa80) at remote.cc:765:5
   762          MsgWriter msg{buffer, MessageType::Command};
   763          msg.write(command);
   764      }
-> 765      write(sock, {buffer.data(), buffer.data() + buffer.size()});

frame #1: 0x0000000102647529 kak`void Kakoune::write<false>(fd=3, data=StringView @ 0x00007ff7bda9f970) at file.cc:268:31
   265
   266      while (count)
   267      {
-> 268          if (ssize_t written = ::write(fd, ptr, count); written != -1)

frame #0: 0x00007ff8012c4846 libsystem_kernel.dylib`write + 10
libsystem_kernel.dylib`write:
->  0x7ff8012c4846 <+10>: jae    0x7ff8012c4850            ; <+20>

The odd thing to me is this (at frame #1):

(lldb) var count
(ssize_t) count = 268522
(lldb) var written
(ssize_t) written = 140702015683112

[krobelus]

(ssize_t) written = 140702015683112

this might jsut be unintialized because write() did not return yet. Maybe what happens here is that EventManager::has_instance() is false (if this is from kak -p) and the write blocks forever for some reason

[krobelus]

Yeah, the length of your string is 268513 but the wire format adds 8 bytes for the length:

    void write_field(StringView str)
    {
        write_field(str.length());
        write_raw(str.data(), (int)str.length());
    };

making it 268522

[krobelus]

so this must be because no one is reading from the fifo/socket

[hadronized]

Okay, I’ll investigate a bit more into the KTS threads then.

[hadronized]

It looks KTS is blocked waiting for the kak -p to exit.

[krobelus]

well yeah that's the write end with the stack trace from above. I realized that the read end must be the Kakoune server. Can you try to attach to that see why it might fail to read?

[hadronized]

I think I understand what’s going on:

1. The KTS Kakoune code asks to highlight to KTS by writing to a FIFO.
2. KTS receives the command, decodes it, computes the highlights and sends it back…
3. But in parallel to that (after having written to the FIFO), Kakoune writes to the FIFO another time to highlight; KTS is single threaded now, and since it wait() for kak -p to finish, it cannot read from the FIFO, and kak -p cannot be executed by Kakoune because it waits on the FIFO. Dead-lock.

I might revert the code to the queue-based thing I used to have, because it looks like this single thread thing is causing more issues than anything else.

[krobelus]

Yeah if KTS is single-threaded and receiving commands on a fifo it needs to have an event loop to unblock Kakoujne in this situation. Instead of a fifo you could maybe use a Unix socket but I don't think it will make a difference

[postsolar]

I noticed if I do :kak-tree-sitter-req-stop and then :kak-tree-sitter-req-highlight-buffer my Kakoune client freezes completely. Related?

[hadronized]

@postsolar not related. I’ll fix that too, it’s not a KTS issue but a Kakoune command thing. Thanks for reporting.