infinite gdb loop on alpha 5.x [matthias.andree@gmx.de: what is _actually_ broken (was: bogofilter-0.17.5 broken on alpha 5)]

Kris Kennaway kris at obsecurity.org
Tue May 25 18:58:26 PDT 2004


Can someone please look at this?  bogofilter is getting itself (well,
gdb) into an infinite loop during one of its self-tests.

Kris

----- Forwarded message from Matthias Andree <matthias.andree at gmx.de> -----

X-Original-To: kkenn at localhost
Delivered-To: kkenn at localhost.obsecurity.org
Delivered-To: kris at freebsd.org
Date: Wed, 26 May 2004 03:16:57 +0200
From: Matthias Andree <matthias.andree at gmx.de>
Subject: what is _actually_ broken (was: bogofilter-0.17.5 broken on alpha 5)
In-reply-to: <20040525232115.GA58377 at xor.obsecurity.org>
To: Kris Kennaway <kris at obsecurity.org>
X-Virus-Scanned: by amavisd-new at m2a2.dyndns.org
User-Agent: Mutt/1.5.5.1i
X-UIDL: Ei7"!LJn"!PPf!!51g"!
X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.17.5

On Tue, 25 May 2004, Kris Kennaway wrote:

> It's doing the 'infinite backtrace' thing again.

Gee. Not again.

> >>> Using exec file "abortme".
> >>> Running command: gdb -nw -r -batch -nx -x script.gdb.55993 -silent abortme ./abortme.core </dev/null
> Core was generated by `abortme'.
> Program terminated with signal 6, Aborted.
> #0  0x1602c48fc in kill () from /lib/libc.so.5
> <<< SIMPLE BACKTRACE <<<
> #0  0x1602c48fc in kill () from /lib/libc.so.5
> #1  0x1602b60f8 in raise () from /lib/libc.so.5
> #2  0x1602b60f8 in raise () from /lib/libc.so.5
> #3  0x1602b60f8 in raise () from /lib/libc.so.5
> [...]

I cannot pinpoint the bug, but I suspect GDB, although it's not the only
possibility.  The whole abortme program is the compiled version of this
trivial program and serves as a quick sanity check of the test suite (as
we used to have b0rked backtraces on exotic platforms upstream):

#include <stdlib.h>

int main(void)
{
    abort();
}

It is a bit strange that GDB chokes on such a simple task, but I know
that GDB on non-mainstream platforms isn't on par with the i386 GDB,
I've seen it fail miserably on a sparc64 running Solaris 8.

The options used are in the config.log file that "make configure" leaves.

I have neither resources (time, test machine) nor sufficient expertise
with alpha to debug this and I need to defer this to external help.

Could you forward this mail to some of the alpha adepts? Someone will
have to figure which component is at fault, and someone might need to
fix this.

We could also limit the impact by running GDB in a subshell and allow it
it only 15 s of CPU time, by patching the core analyzer script.

As a last resort, if several Alpha guys found they could find the
problem, we might just remove t.abort from the list of tests the port
runs, or configure alpha 5 with GDB=${FALSE} or something.

I apologize for not being a better help here, but debugging GDB is
beyond me.

Kind regards,

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95



----- End forwarded message -----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-alpha/attachments/20040525/e398722c/attachment.bin


More information about the freebsd-alpha mailing list