Re: Unexpected pass for t6120-describe.sh on cygwin
- From
Michael J Gruber <git@grubix.eu>
- Date
- Sep 13, 2017, 09:08 UTC
- Message-ID
- <52f990d5-cdac-b516-269c-acbb68897e6e@grubix.eu>
- In-Reply-To
- <alpine.DEB.2.21.1.1709121538360.4132@virtualbox>
Johannes Schindelin venit, vidit, dixit 12.09.2017 15:39:
Show 23 quoted lines
> 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