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
