build failure on sparc64 (was: Re: [cvs] SF.net SVN: bogofilter:[6834] trunk/bogofilter)

[Matthias Andree]

Am 23.06.2009, 23:38 Uhr, schrieb Serafeim Zanikolas <serzan at hellug.gr>:

> Hi all,
>
> On Thu, May 28, 2009 at 05:23:26PM +0200, Matthias Andree wrote [edited]:
>> Am 28.05.2009, 14:06 Uhr, schrieb <m-a at users.sourceforge.net>:
>>
>> > Revision: 6834
> [..]
>> Note that these fixes were required for some systems that suffered build
>> failures otherwise.
>
> As the new maintainer of bogofilter for Debian, I'd like to point out  
> that a test from bogofilter 1.2.0 has failed in sparc64:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526018
>
> and then it built fine on a subsequent try (due to an irrelevant  
> re-upload which didn't change the source in any way). Unfortunately I  
> can't report how often this failure is, as I don't have access to a  
> sparc64 machine.
>
> Any feedback welcome.

Hi Serafeim,

welcome to the job, it's good to see that bogofilter packages for Debian  
continue to be maintained.

I've just tested the SVN checkout (r6836) on an old Sun Ultra 5  
(UltraSPARC IIi in the 333/400 MHz class) running Solaris 8 FCS (for lack  
of a sparc64 running Debian), and the build (GNU make, GCC 3.4.5) and all  
52 tests (we're skipping t.valgrind and t.leakfind there) pass.

I'd say there are two possibilities for the bug:

  - The earlier upload might really have been busted somehow. Auxiliary  
Debian build files can change even if the source does not - but I'm not  
saying this was the cause.

  - The bug submitter's computer had a temporary hicc-up. Such things  
happen, and if that was the case, I've seen several older SPARC computers  
(none with a 200X mfg date) show erratic behaviour and die a few weeks  
later, usually with a fatal backplane (mainboard) fault.

SIGBUS as reported in #526018 would look like unaligned memory access  
which real processors such as M680x0, SPARC or MIPS do not like at all, so  
if the LSB of the PC register was somehow trashed, or a relocated jump  
address was, then this might have caused the problem. Do Debian SPARC  
kernels log corrected RAM errors when using ECC? If so, the submitter's  
log should be checked around crash time for issues with the memory or  
other hardware components.

Hope that helps.

Cheers

-- 
Matthias Andree