I wrote: :James E Keenan <jkeenan@pobox.com> wrote: ::[perl2] $ ./perl -v | head -2 | tail -1 ::This is perl 5, version 31, subversion 3 (v5.31.3) built for ::amd64-freebsd-thread-multi ::[perl2] $ ( cd t ; ./perl op/sprintf2.t >/dev/null ) ; echo $? ::0 ::[perl2] $ ( cd t ; ./perl harness op/sprintf2.t >/dev/null ) ; echo $? ::0 : :Umm, that's 5.31.3, we expected that to pass. : :If you get the same with 5.31.2, try the harness invocation without the :'>/dev/null' - if it still reports a non-zero exit status but itself :exits with 0, we should make a ticket to consider whether that's correct :behaviour. (My guess is that it's not correct, but that it would need :a bunch of toolchain work to propagate the information correctly.) Sorry, that's all garbage, I misread and over-cut. You had also said: :This is perl 5, version 31, subversion 2 (v5.31.2) built for :amd64-freebsd-thread-multi :[perl] $ ( cd t ; ./perl op/sprintf2.t >/dev/null ) ; echo $? :9 :[perl] $ ( cd t ; ./perl harness op/sprintf2.t >/dev/null ) ; echo $? :9 So these cases are both correctly returning non-zero. Needs further investigation to understand where bisect is getting confused: either there's a bug in bisect itself, or it creates an environmental difference. I'll look further tomorrow; I may have to find a way to induce a more reproducible SEGV so I can try it locally, or try again to understand what ether was saying. HugoThread Previous | Thread Next