Date: Tue, 25 May 2004 18:27:31 -0700 From: Kris Kennaway <kris@obsecurity.org> To: alpha@FreeBSD.org Subject: infinite gdb loop on alpha 5.x [matthias.andree@gmx.de: what is _actually_ broken (was: bogofilter-0.17.5 broken on alpha 5)] Message-ID: <20040526012731.GA66033@xor.obsecurity.org>
next in thread | raw e-mail | index | archive | help
--T4sUOijqQbZv57TR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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@gmx.de> -----
X-Original-To: kkenn@localhost
Delivered-To: kkenn@localhost.obsecurity.org
Delivered-To: kris@freebsd.org
Date: Wed, 26 May 2004 03:16:57 +0200
From: Matthias Andree <matthias.andree@gmx.de>
Subject: what is _actually_ broken (was: bogofilter-0.17.5 broken on alpha =
5)
In-reply-to: <20040525232115.GA58377@xor.obsecurity.org>
To: Kris Kennaway <kris@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=3Dbogofilter, spamicity=3D0.000000, version=3D0.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 ab=
ortme ./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=3D${FALSE} or something.
I apologize for not being a better help here, but debugging GDB is
beyond me.
Kind regards,
--=20
Matthias Andree
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95
----- End forwarded message -----
--T4sUOijqQbZv57TR
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFAs/KDWry0BWjoQKURAtuWAKCUXGZWf9/mmVZJ1yGM2z0E5+spmQCg/Mgh
ElPW24CnjZuF7Z5ZoZ7P8rI=
=EA5x
-----END PGP SIGNATURE-----
--T4sUOijqQbZv57TR--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040526012731.GA66033>