Maybe Fossil needs to disable the stack and heap size limits prior to calling exec() or fork() and then reenable the limits afterwards?
On 6/23/17, Warren Young <war...@etr-usa.com> wrote: > 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 > -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev