On Jun 22, 2017, at 8:37 AM, Warren Young <war...@etr-usa.com> wrote: > > On Jun 22, 2017, at 6:23 AM, Warren Young <war...@etr-usa.com> wrote: >> >>> Can you provide a test case?
I’ve got a much better test case now as well as a potential solution. It turns out that the problem has nothing to do with Fossil specifically at all. The following C program — based loosely on the new fossil_limit_memory function — fails on this system until it increases the stack limit to 8 MB: #include <errno.h> #include <stdint.h> #include <stdio.h> #include <sys/resource.h> #include <unistd.h> void fossil_limit_memory(rlim_t nStack) { struct rlimit x; getrlimit(RLIMIT_STACK, &x); x.rlim_cur = nStack; setrlimit(RLIMIT_STACK, &x); } int main(void) { const char* prg = "/usr/bin/vim"; rlim_t n = 2000000; while (1) { fossil_limit_memory(n); int error = execl(prg, prg, (char*)0); if (error == 0) { puts("can't get here"); return 0; } else if (errno == E2BIG) { rlim_t m = n * 2; fprintf(stderr, "Stack limit %d exceeded; trying %d.\n", n, m); n = m; } else { perror("Failed to exec Vim"); return 1; } } } Conjecture: programs on CentOS 7 are built to expect that stack size, and there is some setting in the ELF header that declares the required stack size, so that execl() knows the program won’t even run correctly if loaded under the set limit. _______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev