Getting aborted when running CommnadT in lua version

[mohammad5305]

also I tried with neovim 0.7 and setting ARCHFLAGS to i386 in compile but getting same result os: voidlinux i386 neovim: 0.8 package manager: packer

[wincent]

Thanks for the report @mohammad5305. I have a couple of ideas for how we might gather more information. One is to make a debug build, which you can do like this:

cd ~/.local/share/nvim/site/pack/packer/start/command-t/lua/wincent/commandt/lib
DEBUG=1 make

That will create a build with some assert() calls enabled that might reveal a problem, and it will also write to a log file commandt-debug.log in the current directory (it doesn't actually log much at this time, so you might not see anything in there...).

The other thing you could do is run the test suite:

cd ~/.local/share/nvim/site/pack/packer/start/command-t
bin/test

One final question: what are you doing before and when the abort happens?

[mohammad5305]

test are passing successfully expect one

       SKIP  doesn't show a dotfile just because there was a match at index 0 (fix: see ed01bc6)

and here is log file

and nothing I just open neovim normally without anything else after that when I execute CommandT or other finders I get aborted and i'm back to shell

[wincent]

@mohammad5305: My guess is that because you're on a 32-bit arch our generous allocations of virtual memory are eventually causing the abort (ie. because we're running out of address space).

You could try this patch (which cuts the max file count by 4 and cuts the buffer size by 4 too) and run make again. Potentially even drop the numbers lower if that doesn't work. If we can find "the right" tuning for the parameters, we can bake this into the Makefile so that it will use appropriate limits on 32-bit and 64-bit machines.

diff --git a/lua/wincent/commandt/lib/find.c b/lua/wincent/commandt/lib/find.c
index 2d85e88..f87a76f 100644
--- a/lua/wincent/commandt/lib/find.c
+++ b/lua/wincent/commandt/lib/find.c
@@ -21,8 +21,8 @@
 #include "xstrdup.h" /* for xstrdup() */

 // TODO: share these with scanner.c
-static long MAX_FILES = 134217728; // 128 M candidates.
-static size_t buffer_size = 137438953472; // 128 GB.
+static long MAX_FILES = 33554432; // 32 M candidates.
+static size_t buffer_size = 34359738368; // 32 GB.
 static const char *current_directory = ".";

 find_result_t *commandt_find(const char *directory) {
diff --git a/lua/wincent/commandt/lib/scanner.c b/lua/wincent/commandt/lib/scanner.c
index edea023..7ded5c9 100644
--- a/lua/wincent/commandt/lib/scanner.c
+++ b/lua/wincent/commandt/lib/scanner.c
@@ -19,9 +19,9 @@
 // TODO: make this capable of producing asynchronously?

 // TODO make this configurable
-static long MAX_FILES = 134217728; // 128 M candidates.
-
-static size_t buffer_size = 137438953472; // 128 GB.
+static long MAX_FILES = 33554432; // 32 M candidates.
+                                  //
+static size_t buffer_size = 34359738368; // 32 GB.

 scanner_t *scanner_new_copy(const char **candidates, unsigned count) {
     scanner_t *scanner = xcalloc(1, sizeof(scanner_t));

[mohammad5305]

yeah the problem fixed thanks

[wincent]

Thanks for confirming, @mohammad5305.

I pushed a tweak in https://github.com/wincent/command-t/commit/7b47958d1ded797585ed512ef3a45cea88f65740 that should make this automatic — based on the output of getconf LONG_BIT (which should be 32 or 64, typically), it will pick suitable values for the memory allocations. 🤞

[mohammad5305]

looks like the commit have some problems

[wincent]

Thanks for letting me know, @mohammad5305.

• The good news: this shows that the build is correctly identifying your system as 32-bit.
• The bad news: I had a copy-paste error in the 32-bit code where I forgot to include the -D prefix in the relevant parts of the Makefile.

Fixed that in https://github.com/wincent/command-t/commit/6c8e2a3e3b5acd004ef0ba8cf367a626552aab90.