-
Notifications
You must be signed in to change notification settings - Fork 321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Getting aborted when running CommnadT in lua version #399
Comments
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:
That will create a build with some The other thing you could do is run the test suite:
One final question: what are you doing before and when the abort happens? |
test are passing successfully expect one
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 |
@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 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)); |
yeah the problem fixed thanks |
To deal with the aborts reported in: #399 My theory was that on a 32-bit machine an allocation was failing due to the rather generous sizes involved, given that the DEBUG build showed the tests passing, and some allocations were recorded in the `commandt-debug.log` We tried with smaller sizes (1/4 of the previous sizes) and the aborts went away. These sizes are still ridiculously large. The smaller sizes correspond up to 32 million candidate strings (the largest projects I've ever worked with or even heard of had anywhere between 1.5 M and 4 M strings; I expect that anybody working on anything larger than that is very, very likely running on a 64-bit architecture), and a string storage slab of 32 G (the way the math works out here is if you had 32 M strings of length 1K you'd fill up all the space). So, in this commit, we do some basic autodetection based on `getconf LONG_BIT` (which is POSIX, so should be relatively portable, even if it isn't super informative) and use that to decide how big the numbers should be. We may still want to make this overridable by users, or otherwise more sophisticated, but until I see a demand for that, I'll hold off. The `compile_flags.txt` file is so that `clangd` can know what the preprocessor options are going to resemble (obviously, these are hard-coded, so really are just intended to keep the LSP from complaining about undeclared identifiers).
Thanks for confirming, @mohammad5305. I pushed a tweak in 7b47958 that should make this automatic — based on the output of |
Thanks for letting me know, @mohammad5305.
Fixed that in 6c8e2a3. |
To deal with the aborts reported in: wincent/command-t#399 My theory was that on a 32-bit machine an allocation was failing due to the rather generous sizes involved, given that the DEBUG build showed the tests passing, and some allocations were recorded in the `commandt-debug.log` We tried with smaller sizes (1/4 of the previous sizes) and the aborts went away. These sizes are still ridiculously large. The smaller sizes correspond up to 32 million candidate strings (the largest projects I've ever worked with or even heard of had anywhere between 1.5 M and 4 M strings; I expect that anybody working on anything larger than that is very, very likely running on a 64-bit architecture), and a string storage slab of 32 G (the way the math works out here is if you had 32 M strings of length 1K you'd fill up all the space). So, in this commit, we do some basic autodetection based on `getconf LONG_BIT` (which is POSIX, so should be relatively portable, even if it isn't super informative) and use that to decide how big the numbers should be. We may still want to make this overridable by users, or otherwise more sophisticated, but until I see a demand for that, I'll hold off. The `compile_flags.txt` file is so that `clangd` can know what the preprocessor options are going to resemble (obviously, these are hard-coded, so really are just intended to keep the LSP from complaining about undeclared identifiers).
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
The text was updated successfully, but these errors were encountered: