[LLVMdev] LLVM on OpenBSD

[Joachim Durchholz]

Am Mittwoch, den 18.06.2008, 14:08 +0100 schrieb Edd Barrett:
> Sometimes you get a clean build of llvm, sometimes you don't and instead
> get a bus error.

Nonreproducible behaviour in a batch application is usually a sign of
hardware problems.

> > In the linux-community, people say that bus-error's are almost 
> > always because of faulty hardware, e.g. problem with DRAM 
> > timing, overheated CPU, power-supply that cannot provide enought 
> > power during current surges, things like that.
> 
> That is one reason a bus error might occur, but my more common
> understanding of a bus error is data not properly aligned with the byte
> boundaries and/or out of range memory at the physical level.

Bus errors are usually the result of pointers getting corrupted.
That may be due to a bug, or due to hardware problems.

> The machine I am building on is my workstation which I use 9-4.30
> mon-fri. I run all manner of apps without any problems, so if it were
> bad hardware it would have shown itself by now surely.

Not really. gcc produces a different kind of load than most
applications.

> As a test I got another developer to try on a different machine and he 
> has the same problem.

It is possible that both hardwares are faulty, though it reduces the
probability considerably.

> In another test he  also tried a more aggressive 
> malloc.conf (a mechanism which causes malloc to do all sorts of 
> randomisation and page filling to test for memory based bugs) and a 
> completely different error was encountered:
> 
> SelectionDAG.cpp:2602: warning: converting of negative value
> `-1' to `long long

If you get irreproducible bus errors, that means random rare pointer
corruption, and pointer corruption can cause almost arbitrary fault
behaviour.
So if you change the environment, pointer corruption will change the
fault behaviour, regardless of whether the corruption is due to hardware
or software.

> Also we found that without specifying --enable-optimized, the 
> optimisations were still present:
> 
> -O3 -fomit-frame-pointer -Woverloaded-virtual -pedantic
> -Wall -W -Wwrite-strings -Wno-long-long -Wunused -Wno-unused-parameter
> -O3
> 
> :¬(

Can't comment on that one.


Try writing a script that populates an empty directory and does the
build. That way, you can guarantee identical environments (modulo
machine load and filesystem storage layout, but that should not
influence what batch programs like LLVM do).
If you get the same bus errors after deleting the directory and starting
over, it's probably a software problem. If the bus errors stay random,
that would incrase the probability of a hardware problem.

Regards,
Jo