Follow-up promised after my remarks about quality of Megapov 1.2.1 release.

Problem: Megapov 1.2.1 as compiled by Christoph (binary download) or
compiled by myself (source download) using the default ./configure
settings, crashes and/or hangs my Athlon XP with Gentoo Linux 2.6.12.

Which scene ?
Halfway through projection.pov  and at approx 75% of the cube animation.

Its your hardware !!!!
No. Booted into memtest86+, let it run for a night, no problems.
Booted into XP (yes I have to admit, I still have a XP partition)
downloaded Megapov 1.2.1 for Win. All scenes rendered ok.

It's your kernel/glibc etc. !!
No. Got a free Suse 9.3 disk from a magazin, installed on free
partition: same errors. Installed new Gentoo 2005.1 release: same errors.

You run a patched version.
No. Downloaded stock versions of PovRay 3.6.1. and Megapov 1.2.1,
installed on empty partition and compiled using default settings.

Any progress ?
Yes. Recompiled with: ./configure --disable-optimiz  Slow as turtle, but
completed the scenes. Added, one-by-one, "O1" "-march=athlon-xp" "02"
"-fomit-frame-pointer" and finaly "O3" and "-ffast-math". I am currently
enjoying a stable version !!

Configured with:
./configure COMPILED_BY="Willem" --disable-optimiz
CXXFLAGS="-march=athlon-xp -ffast-math -O3 -fomit-frame-pointer -pipe"
CFLAGS="-O3 -march=athlon-xp -ffast-math -fomit-frame-pointer -pipe"

Anyone else using the unix version ??

Post a reply to this message

> ./configure COMPILED_BY="Willem" --disable-optimiz
> CXXFLAGS="-march=athlon-xp -ffast-math -O3 -fomit-frame-pointer -pipe"
> CFLAGS="-O3 -march=athlon-xp -ffast-math -fomit-frame-pointer -pipe"

	If I undestand your previous messages correctly, you get a buggy
binary while building with default configure options.  It would be quite
useful to know what are the default compiler flags that configure sets
for you to compare with those above.

	- NC

Post a reply to this message

Willem <Willem> wrote:
> It's your kernel/glibc etc. !!
> No. Got a free Suse 9.3 disk from a magazin, installed on free
> partition: same errors. Installed new Gentoo 2005.1 release: same errors.

So there is still a kernel panic when you run MegaPOV with any of those
kernels?

Post a reply to this message

nomail wrote:
> Willem <Willem> wrote:
> 
>>It's your kernel/glibc etc. !!
>>No. Got a free Suse 9.3 disk from a magazin, installed on free
>>partition: same errors. Installed new Gentoo 2005.1 release: same errors.
> 
> 
> So there is still a kernel panic when you run MegaPOV with any of those
> kernels?

On my machine, yes.

Post a reply to this message

Willem <Willem> wrote:
> On my machine, yes.

Well, then you have found a kernel bug and should report it to the kernel
developers. The kernel should never crash no matter what an application
does. There is no reliable way of telling if there is a bug in MegaPOV or
not as long as the kernel crashes. Of course, it is likely possible to
modify MegaPOV to not trigger the kernel bug or work around it some other
way, but that does not imply there is a bug in MegaPOV at all.

Post a reply to this message

Willem wrote:
> 
> Any progress ?
> Yes. Recompiled with: ./configure --disable-optimiz  Slow as turtle, but
> completed the scenes. Added, one-by-one, "O1" "-march=athlon-xp" "02"
> "-fomit-frame-pointer" and finaly "O3" and "-ffast-math". I am currently
> enjoying a stable version !!

If your compiler produces a faulty binary with one set of options and a 
working one with a different set that's a bug in the compiler.

Both the binary version from the website (using -O3 -march=i586) and the 
default options (here: -O3 -ffast-math -malign-double 
-minline-all-stringops -m3dnow -march=athlon-xp -mtune=athlon-xp)

work without problems (both using unpatched gcc 3.4.3).

As Nicolas said it would be important to mention what the default 
options are for you.

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.tu-bs.de/~y0013390/ (Last updated 24 Jul. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

Christoph Hormann wrote:
> If your compiler produces a faulty binary with one set of options and a
> working one with a different set that's a bug in the compiler.
Nope, not all code can handle all levels of optimisations well. Lets
assume, for the sake of argument, that Gcc 3.4.3 is stable, since we all
use it ;). Yet I know know numerous programs which can only be compiled
using special flags, or without any Ox-flag at all.

I did some physical modelling with a program called, p3d, which
generated completely different results when compiled with different
settings. This program too, like MegaPov, was dealing with floating
numbers which could differ only in order of magnitude like 1e-7.
Suddenly compiler option are not trivial anymore, although
theoretically, it should be just fine.

> Both the binary version from the website (using -O3 -march=i586) and the
> default options (here: -O3 -ffast-math -malign-double
> -minline-all-stringops -m3dnow -march=athlon-xp -mtune=athlon-xp)
If I run ./configure without options the following flags are produced in
the Makefile:
CXXFLAGS =  -pipe -Wno-multichar -s -O3 -ffast-math -malign-double
-minline-all-stringops -m3dnow -march=athlon-xp -mtune=athlon-xp

Which are exactly the same flags you have.....

Nomail wrote:
> Well, then you have found a kernel bug and should report it to
> the kernel developers.
Always look in the mirror first. Especially if you compile with
"-ffast-math". The compiler generates code which directly accesses the
FPU to perform i.e sin,cos operations en there is no checking for NaN of
Zero; this is responsibility of the programmer. Strange things can &
will happen !!

Anyway, interesting to see that all no-one (!) accepts the possibility
that the MegaPov distribution could contain a error. Although it most
probably does not contain serious bugs, Christoph does a great job here,
 not too many people use it on a linux-box, so there could always be
"something" if compiled on a different Unix-box. Yet all fingers pointed
directly at my hardware, my kernel, my compiler and my dog.

Was the problem itself or did I use foul language ?

So I restate my question: Is anyone using a self-compiled version of
MegaPov and does it run all supplied scenes without trouble ?

I Do !! My Megapov-version is, right now, happily processing,
yet-another-stupid ball-hits-block-animation.

Always willing to help out ;)

Post a reply to this message

I have been following this for a while, so maybe this helps you understand a 
bit better what you need to do.  While I respond to everything in your 
message, the important part is in the last two paragraphs.

> Nope, not all code can handle all levels of optimisations well. Lets
> assume, for the sake of argument, that Gcc 3.4.3 is stable, since we all
> use it ;).

Note that there are 166 bugs in 3.4.3 which were fixed in 3.4.4 alone.  Of 
course, if gcc is buggy or not has nothing to do with the problem at hand.

> Yet I know know numerous programs which can only be compiled
> using special flags, or without any Ox-flag at all.

Which is 99.9% of all cases indicates either a bug in the programs, the 
compiler performing certain optimizations or a user misunderstanding the 
proper configuration of compiler optimization options.  Of course, this also 
has nothing to do with the problem at hand.

> I did some physical modelling with a program called, p3d, which
> generated completely different results when compiled with different
> settings. This program too, like MegaPov, was dealing with floating
> numbers which could differ only in order of magnitude like 1e-7.
> Suddenly compiler option are not trivial anymore, although
> theoretically, it should be just fine.

Your statement, while being correct in the observation that certain compiler 
options may influence floating-point precision (for various reasons, non of 
which are bugs at all), has nothing to do with the problem at hand. In fact, 
it shows a clear misunderstanding of the nature of the problem.

> Always look in the mirror first. Especially if you compile with
> "-ffast-math". The compiler generates code which directly accesses the
> FPU to perform i.e sin,cos operations 

This is plain wrong, this is not what "-ffast-math" is about.  "-ffast-math" 
is nothing more than shortcut to enable various generally non-IEEE/ISO 
conforming floating-point optimizations (and the example you mention isn't 
one of them).  And it has, just like all the things you mentioned so far, 
nothing to do with the problem at hand.

> en there is no checking for NaN of
> Zero; this is responsibility of the programmer. Strange things can &
> will happen !!

Nothing strange can happen, the behavior is complete deterministic (except 
of certain generations of P1s, of course ;-) ) and completely predictable. 
And this also has nothing to do with the problem at hand.

> Anyway, interesting to see that all no-one (!) accepts the possibility
> that the MegaPov distribution could contain a error.

No, it is you who does not understand what many people have told you so far: 
  Somehow you have run into a dead end and are now pushing against a wall, 
not listing to anybody else who is trying to tell you to just turn around to 
get out of the deadened and find a solution to your problem ;-)

Nobody can reproduce your bug and you cannot expect help if you refuse to 
get a fixed kernel.  It has already been pointed out to you that you need to 
get a fixed kernel first.  A kernel panic isn't pov's fault no matter how 
you twist and turn it.

Once your kernel is fixed, one of two things can happen: Either MegaPOV 
works, or you get a reasonable crash of MegaPOV without a kernel panic.  In 
the former case you can just be happy, in the later you will need to come 
back with a bug report.  The neat thing is once your kernel no longer 
panics, and if there should indeed be a problem in MegaPOV, you can include 
a stack trace and other relevant information along with your report.

	Thorsten Froehlich, POV-Team

Post a reply to this message

Oops,

I clearly forgot to mention that I indeed was worried
about the system crash. Although the kernel served me well for months, I
discarded it and I switched to a "official" stable kernel,
recompiled Gcc & Glibc just for good measure. Nor more
system crashes as noted in my first post last week. The feedback was
right; a program crash should be handled by the OS.

That is why I promised to do a follow-up. I purposely installed two
clean distributions, with proper, stable, non-patched kernels.
Unfortunately the MegaPov behaviour persisted, but those collapses were
handled correctly by the O.S. I did not mention "system crashes" at all
in my follow-up.

Thorsten Froehlich wrote:
> Which is 99.9% of all cases indicates either a bug in the programs, the
> compiler performing certain optimizations or a user misunderstanding the
> proper configuration of compiler optimization options.  Of course, this
> also has nothing to do with the problem at hand.
Could you please explain? This could be exactly the problem we deal
with. MegaPov could have bugs; 1.2.1 is a bug-release, and the
./configure script could have generated compiler flags which uncovers
these bugs. Remember, ./configure is dynamic script, trying to make
educated guess to which compiler flags are best for your specific
Unix-box. Thats why I started hard-coding these flags, in order to make
sure I could produce a correct binary for my machine.

> Nothing strange can happen, the behavior is complete deterministic
> (except of certain generations of P1s, of course ;-) ) and completely
> predictable. And this also has nothing to do with the problem at hand.
Sorry, joyfull language obscured the message: it is deterministic: it dies.

> No, it is you who does not understand what many people have told you so
> far:  Somehow you have run into a dead end and are now pushing against a
> wall, not listing to anybody else who is trying to tell you to just turn
> around to get out of the deadened and find a solution to your problem ;-)
See first paragraph. I did address the kernel issue right away. I try to
be open-minded.

> Nobody can reproduce your bug 
No-one has either confirmed, nor rejected the bug.

> ..include a stack trace....
I'd love to. I will google for a HowTo.

Are you realy sure about the --fast-math ? It is just so typical for
MegaPov, with all the physics code and the ininitesimal calculations
associated. I have seen so many physical simulations die because the
approximations were approaching Zero en there was just not enough
boudary checking..because there never is time/imagination to prevent
them all... I hated it too when wrote those programs.

Anyway, I try to cooperate :)

Post a reply to this message

Willem wrote:
> That is why I promised to do a follow-up. I purposely installed two
> clean distributions, with proper, stable, non-patched kernels.
> Unfortunately the MegaPov behaviour persisted, but those collapses were
> handled correctly by the O.S. I did not mention "system crashes" at all
> in my follow-up.

Hmm, five hours ago you said something different ;-)


-------- Original Message --------
Subject: Re: Megapov 1.2.1 Linux - Followup
Date: Mon, 12 Sep 2005 18:23:03 +0200
From: Willem <Willem>
Newsgroups: povray.unofficial.patches

nomail wrote:
 > Willem <Willem> wrote:
 >
 >>It's your kernel/glibc etc. !!
 >>No. Got a free Suse 9.3 disk from a magazin, installed on free
 >>partition: same errors. Installed new Gentoo 2005.1 release: same errors.
 >
 >
 > So there is still a kernel panic when you run MegaPOV with any of those
 > kernels?

On my machine, yes.

Post a reply to this message