Re: [Bashdb-devel] bashdb 3.1-0.08 test failures under cygwin

[Rocky B. <roc...@gm...>]

Comments in line .

On 4/28/07, Eric Blake <eb...@by...> queries and avows:
>
> According to Rocky Bernstein on 4/24/2007 2:08 AM:
> > I've just compiled bash 3.2.15 on GNU/Linux (with gcc version 4.1.0 and
> > -O2 optimization). I was able to run the regression tests without any
> > errors both on bashdb 3.1-0.08 and current CVS sources.
> >
> > On cygwin where I noticed a failure, I was using the installed bash from
> > the Interent. Furthermore  bashdb wasn't using readarray the C-compiled
> > extension.
>
> Have you had any success getting cygwin bash to use loadable modules, such
> as readarray?


I deliberately did not  because there was a failure and I wanted to rule out
the possibility of this being caused by a readarray bug. Since it failed
without readarray, I fail to see how compiling readarry would fix  the
problem! And unlikeliness aside,  I'm not sure how helpful it would have
been to know that.

Furthermore, my recollection is that cygwin ships bashdb with readarray
compiled. It is one of the few distributions to do that - thank you very
much!

(In my own experience using readarray  greatly speeds up initial load time.
With luck and probably lots of persistence on Misatake's part, it will get
back into bash proper at some point.)

>
> > Given this, right now the evidence suggests that the problem mentioned
> > in this thread is in the bash 3.2.15 binary on cygwin.
>
> Indeed it was.  There are latent bugs in the bash source code, where
> various builtins leak output to the wrong file if stdio is not line
> buffered; but cygwin bash had a local patch that did just that in order to
> fix another bug where builtins incorrectly used text mode instead of
> binary mode to talk over pipes.  I've uploaded a new version of bash for
> cygwin that has the problem with builtins fixed, and verified that the
> bashdb testsuite passes again.



long rant...

My take is that there are a couple of lessons here. First, test suites are
good. They help you find bugs and verify the correct working of a program.
Second, this is not the first time the test suite for bashdb has shown a
presence of a bash bug. The bash test suite, while useful, has clearly been
a bit lacking.

Back when I was hacking on bash to add better debugger run-time support and
the timestamped history, I made a stab at improving the bash test suite so
it would be more automatic by not complaining as much when there is no
problem, make running tests individually easier, and use more of the
standard auto* test framework. Alas those changes didn't make it back into
the source.

It would be wise before a bash release to try out bashdb and run its test
suite. Not just because it would be a nice thing to do for bashdb (or more
precisely its users), but because it constitutes a large bash program that's
freely available in GPL; in that category it isone of the few that does come
with regression tests!

It is not clear to me that before a general bash release, there is  testing
done using such a large complete bash program. Small unit tests are great,
especially when they are carefully crafted and religiously applied via
test-driven development (which is probably not the case here). But a second
independent confirmation would be nice too.

Alas, I don't have the time (nor find it satisfying)  to keep tabs on the
bugs bash introduced between releases. Perhaps there's a kinder, more
tolerant soul out there who could help the community out by undertaking such
a task.

--
> Don't work too hard, make some time for fun as well!


I'm not that good - I have to work hard in order to get anything done.

Eric Blake             eb...@by...
>
>
>