0.11.1 debian failures

[Matthias Andree]

David Relson <relson at osagesoftware.com> writes:

> Given that S390's with Debian aren't readily available and knowing
> Clint's interest in bogofilter, I think it reasonable to suggest dealing
> with a script and core file.  The core file and the bogofilter
> executable aren't enough for us without an S390 to run gdb.  I had
> suggested an alternative approach to him, i.e. that he run bogofilter
> under gdb and get the stack backtrace when bogofilter blows up.

I have automated that with the "printcore" patch I put into the CVS
trunk, after each test, it looks for files that match grep -w core, and
it tries to extract the executable name from the first file is has found
that way, and then runs a short gdb batch file on the executable and
core file. I've tested the patches on the usual suspect machines and
found them working OK, and unless some shell really blows up (even
Solaris sh seems fine with that stuff), it should cope with gdb not
being installed by not providing a backtrace ;-)

(BTW, I found out the hard way that Solaris /bin/sh doesn't really like
$( command ), it insists on `command`.)

I have found the file-finding tricks to be necessary as various
operating systems write core files as PROGRAM.core or core.12345.

> Since the problem shows up in a locking test, the odds are that it
> relates to the locking code.

It might just as well trigger a bug in our initialization.

> An alternative approach would to create a series of small programs
> that test different parts of the locking code.  Running the tests
> would reveal what's wrong.  Of course, it's guess work to generate the
> right set of small programs and it might be a significant amount of
> trouble.

I don't like shooting into the dark blue...

-- 
Matthias Andree