Am 04.03.2016 um 19:25 schrieb ThH:
> Am 04.03.2016 um 18:59 schrieb clipka:
> 
>> Hey, it's an issue reported by ThH. _Of course_ it works perfectly fine
>> on Windows >_<
> 
> Haha :D
> 
> No reason for me to change the OS ;))
> 
> Just hoping it's your natural interest to get it fixed for Linux users :))

It is. But alas! ...

Well, you probably know the drill: Toy around and try to figure out
/some/ useful information.

@Jerome: Care to do some "binary search" again to narrow down the
offending version?

(Let me guess: It's that range of commits again that refuses to compile
on Linux, right?)

Post a reply to this message

Am 04.03.2016 um 19:51 schrieb Le_Forgeron:
> Le 04/03/2016 19:41, William F Pokorny a écrit :

> Nope, even with a produced "right" picture, valgrind reports a definitive problem of
uninitialised data.

If valgrind was right, that would certainly explain the problems.
Unfortunately it's mistaken.

Valgrind's report indicates that Bezier_Node_Struct::Radius_Squared is
not (or not always) initialized properly when
BicubicPatch::bezier_tree_walker() is called.

But if that is the case, then adding

    Node->Radius_Squared = -1;

to BicubicPatch::create_new_bezier_node() and adding

    POV_ASSERT(Node->Radius_Squared >= 0);

to the beginning of BicubicPatch::bezier_tree_walker() should force the
code to bomb.

It doesn't. Valgrind must be seeing ghosts.

Post a reply to this message

Am 05.03.2016 um 08:54 schrieb clipka:

> Well, you probably know the drill: Toy around and try to figure out
> /some/ useful information.

SIR YESSSS SIR... Just had some other things to do... SIR !

8< snip >8
//bicubic_patch { type 1 flatness 0.1  u_steps 8  v_steps 8
bicubic_patch { type 0 flatness 0.1  u_steps 8  v_steps 8
8< snip >8

Line 1: no_image effect ;)

Line 2: 8D

SIR!

Time for breakfast here...

Post a reply to this message

Am 05.03.2016 um 10:11 schrieb ThH:
> Am 05.03.2016 um 08:54 schrieb clipka:
> 
>> Well, you probably know the drill: Toy around and try to figure out
>> /some/ useful information.
> 
> SIR YESSSS SIR... Just had some other things to do... SIR !

SOLDIER, I don't remember having ordered you to do OTHER THINGS!

> 8< snip >8
> //bicubic_patch { type 1 flatness 0.1  u_steps 8  v_steps 8
> bicubic_patch { type 0 flatness 0.1  u_steps 8  v_steps 8
> 8< snip >8
> 
> Line 1: no_image effect ;)
> 
> Line 2: 8D

Does that mean "it works"?

Post a reply to this message

Am 05.03.2016 um 10:19 schrieb clipka:

> SOLDIER, I don't remember having ordered you to do OTHER THINGS!

Sir soldier used it's brain SIR !

>> Line 2: 8D
>
> Does that mean "it works"?

Yes.

Post a reply to this message

Le 05/03/2016 09:14, clipka a écrit :
> Am 04.03.2016 um 19:51 schrieb Le_Forgeron:
>> Le 04/03/2016 19:41, William F Pokorny a écrit :
> 
>> Nope, even with a produced "right" picture, valgrind reports a definitive problem
of uninitialised data.
> 
> If valgrind was right, that would certainly explain the problems.
> Unfortunately it's mistaken.
> 
> Valgrind's report indicates that Bezier_Node_Struct::Radius_Squared is
> not (or not always) initialized properly when
> BicubicPatch::bezier_tree_walker() is called.
> 
> But if that is the case, then adding
> 
>     Node->Radius_Squared = -1;
> 
> to BicubicPatch::create_new_bezier_node() and adding
> 
>     POV_ASSERT(Node->Radius_Squared >= 0);
> 
> to the beginning of BicubicPatch::bezier_tree_walker() should force the
> code to bomb.
> 
> It doesn't. Valgrind must be seeing ghosts.
> 

I do not say that the Radius_Squared is not initialized...

but adding

memset(Node, 0, sizeof(BEZIER_NODE));

in create_new_bezier_node does remove the issue with valgrind.

Now, remember that we are using -O3 as default level of optimisation,
which means the execution can be reported on line X while the compiler
is actually performing some operations of line X-1 or X+1.

And we are dealing with an hybride code: the declaration of Bezier_Node_Struct is a
100% C++ thing,
with an implicit constructor that would call Véctor3d constructor for Center,
yet create_new_bezier_node is a C thing, calling a memory allocator and casting the
type.

The other members of Bezier_Node_Struct are still C thing, so they are not
initialised.

Nevertheless, for Center, the code that computes it has been "optimised".
Instead of using a temporary variable, initialised to 0 (xc, yc, zc), to add the
various contributions
and then copying the result in Center at the end, the function now add directly the
various contributions
to Center. But what if... you start with *garbage* in Center ? Garbage in, Garbage
out.
(it's in bezier_bounding_sphere() )

And to finish it (give me a hammer, that's the last nail on the coffin):
 If I replace the memset over the whole structure with just (in addition to Data_Ptr =
NULL):

 Node->Center = Vector3d();

valgrind become as happy as with the full initialisation.


Even a bigger hammer: if I use memset with a value of 0xFF (instead of 0), I get a
100% background image.
Reliably.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> Even a bigger hammer: if I use memset with a value of 0xFF (instead of 0), I get a
100% background image.
> Reliably.

That did the trick.
Found the culprit and about to submit a fix any moment now.

Post a reply to this message

ThH <no.spam@address> wrote:
> I don't see a bicubic_patch 8[

Please test the newest master.

Post a reply to this message

Le 05/03/2016 17:37, clipka a écrit :
> ThH <no.spam@address> wrote:
>> I don't see a bicubic_patch 8[
> 
> Please test the newest master.
> 

POV-Ray 3.7.1-alpha.8508492.unofficial seems ok, at least for valgrind (but I was only
getting small artefacts, randomly)

Post a reply to this message

Good to be back on news.povray.org:119 !

Am 05.03.2016 um 17:37 schrieb clipka:

> Please test the newest master.

Bezier is fine now. Thanks clipka :))

--
Thorsten aka ThH
povray --V
POV-Ray 3.7.1-alpha.8508492.unofficial

Post a reply to this message