[Varnish] #1201: Test r01109.vtc reliably fails on FreeBSD (32bit)

[Varnish]

#1201: Test r01109.vtc reliably fails on FreeBSD (32bit)
-------------------------+--------------------
 Reporter:  mi           |       Owner:  phk
     Type:  defect       |      Status:  new
 Priority:  normal       |   Milestone:
Component:  varnishtest  |     Version:  3.0.3
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+--------------------

Comment (by mi):

 Yes, the explicit stack-size helped. Thank you, I'll work on adding the
 above to FreeBSD port www/varnish. Is this a valid fix, however, or a
 work-around? Should varnish's default be higher on 32-bit systems? Also,
 should not varnish react in a more civilized manner in such cases?

 BTW, are tests dependent on each other in any way? In other words, does
 the sequence matter? I'm running with TESTS_PARALLELISM=-j8 (I have 8 CPU-
 cores here) and just had a sudden failure of c00022.vtc, which ''went away
 simply upon rerunning'':
 {{{
 ######## ./tests/c00022.vtc ########
 Assert error in VSL_Open_CallBack(), vsl.c line 366:
   Condition(sha != NULL) not true.
 ######## ./tests/c00022.vtc ########
   errno = 2 (No such file or directory)
 **** top   0.0 macro def varnishd=../varnishd/varnishd
 **** top   0.0 macro def
 pwd=/mi/ports/www/varnish/work/varnish-3.0.3/bin/varnishtest
 **** top   0.0 macro def
 topbuild=/mi/ports/www/varnish/work/varnish-3.0.3/bin/varnishtest/../..
 **** top   0.0 macro def bad_ip=10.255.255.255
 **** top   0.0 macro def tmpdir=/tmp/vtc.54579.21dd1466
 *    top   0.0 TEST ./tests/c00022.vtc starting
 ***  top   0.0 varnishtest
 *    top   0.0 TEST Test banning a url with VCL ban
 ***  top   0.0 server
 **   s1    0.0 Starting server
 **** s1    0.0 macro def s1_addr=127.0.0.1
 **** s1    0.0 macro def s1_port=64893
 **** s1    0.0 macro def s1_sock=127.0.0.1 64893
 *    s1    0.0 Listen on 127.0.0.1 64893
 ***  top   0.0 varnish
 **   s1    0.0 Started on 127.0.0.1 64893
 **   v1    0.1 Launch
 ***  v1    0.1 CMD: cd ${pwd} && ${varnishd} -d -d -n
 /tmp/vtc.54579.21dd1466/v1 -l 10m,1m,- -p auto_restart=off -p
 syslog_cli_traffic=off -a '127.0.0.1:0' -S /tmp/vtc.54579.21dd1466/v1/_S
 -M '127.0.0.1 64896' -P /tmp/vtc.54579.21dd1466/v1/varnishd.pid
 -sfile,/tmp/vtc.54579.21dd1466/v1,10M
 ***  v1    0.1 CMD: cd
 /mi/ports/www/varnish/work/varnish-3.0.3/bin/varnishtest &&
 ../varnishd/varnishd -d -d -n /tmp/vtc.54579.21dd1466/v1 -l 10m,1m,- -p
 auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S
 /tmp/vtc.54579.21dd1466/v1/_S -M '127.0.0.1 64896' -P
 /tmp/vtc.54579.21dd1466/v1/varnishd.pid
 -sfile,/tmp/vtc.54579.21dd1466/v1,10M
 ***  v1    0.2 PID: 56127
 ***  v1    1.0 debug| Platform:
 FreeBSD,8.3-STABLE,i386,-sfile,-smalloc,-hcritbit\n
 ***  v1    1.0 debug| 200 236     \n
 ***  v1    1.0 debug| -----------------------------\n
 ***  v1    1.0 debug| Varnish Cache CLI 1.0\n
 ***  v1    1.0 debug| -----------------------------\n
 ***  v1    1.0 debug| FreeBSD,8.3-STABLE,i386,-sfile,-smalloc,-hcritbit\n
 ***  v1    1.0 debug| \n
 ***  v1    1.0 debug| Type 'help' for command list.\n
 ***  v1    1.0 debug| Type 'quit' to close CLI session.\n
 ***  v1    1.0 debug| Type 'start' to launch worker process.\n
 ***  v1    1.0 debug| \n

 #     top  TEST ./tests/c00022.vtc FAILED (1.000) signal=6 exit=0
 }}}

 I would've filed a separate bug-report, but I can not easily reproduce the
 above. If -j8 is too aggressive, I'll go back to the default -j3.

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1201#comment:4>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator