Johannes Schindelin venit, vidit, dixit 12.09.2017 15:39: > Hi Ramsay, > > On Sat, 9 Sep 2017, Ramsay Jones wrote: > >> I ran the test-suite on the 'pu' branch last night (simply because that >> was what I had built at the time!), which resulted in a PASS, but t6120 >> was showing a 'TODO passed' for #52. >> >> This is a test introduced by Michael's 'mg/name-rev-tests-with-short-stack' >> branch, which uses 'ulimit -s' to try and force a stack overflow. >> Unfortunately, 'ulimit -s' seems to have no effect on cygwin. I created >> a test program (see below) to eat up the stack and tried running it with >> various ulimit values (128, 12, 8), but it always seg-faulted at the >> same stack-frame. (after using approx 2MB stack space). >> >> So, it looks like all ULIMIT_STACK_SIZE tests need to be disabled >> on cygwin. I also wonder about the ULIMIT_FILE_DESCRIPTORS tests, but >> haven't looked into it. >> >> Given that 'ulimit' is a bash built-in, this may also be a problem on >> MinGW and Git-For-Windows, but I can't test on those platforms. > > It is. Thanks. I just dug something up from an old cygwin list post. Could you please try and report on the following (cygwin, MinGW): ulimit -s ulimit -s 4096 # anything lower than the value from above ulimit -s bash -c "ulimit -s" My suspicion from that post is that ulimit affects the sub shell only - if yes, running a test inside the sub shell to confirm whether the setting is in effect would be great, of course. /usr/bin/echo $(seq 100000) or such does the job on Linux (with stack limit 128), but I don't know whether this is portably reliable. If ulimit on these platforms has no effect but does not lie about the value either it's a simple prerequisite test (test ulimit present, if yes set and get and compare the stack size values). Michael
