Am 04.03.2016 um 19:01 schrieb Le_Forgeron:
> Le 04/03/2016 17:22, William F Pokorny a écrit :
...
>> Same here. The patch disappears in 3.7.1-alpha.8499454 while it works in
3.7.0-stable.
> 
> Testing 3.7.1-alpha.8503825.unofficial, the object is there, same as with stable
version.

While I did my own testing with 3.7.1-alpha.8503825 as well, I'd be
quite surprised if any of the changes since alpha.8499454 had fixed it.
They appear to be as unrelated as I could possibly imagine.

Post a reply to this message

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 :))

Post a reply to this message

On 03/04/2016 01:22 PM, clipka wrote:
> Am 04.03.2016 um 19:01 schrieb Le_Forgeron:
>> Le 04/03/2016 17:22, William F Pokorny a écrit :
> ...
>>> Same here. The patch disappears in 3.7.1-alpha.8499454 while it works in
3.7.0-stable.
>>
>> Testing 3.7.1-alpha.8503825.unofficial, the object is there, same as with stable
version.
>
> While I did my own testing with 3.7.1-alpha.8503825 as well, I'd be
> quite surprised if any of the changes since alpha.8499454 had fixed it.
> They appear to be as unrelated as I could possibly imagine.
>
Think you are correct. I just pulled and compiled 3.7.1-alpha.8503825 on 
seeing Jérôme at a newer version, but still nothing (no ray patch 
intersections are found). So maybe a 14.04 vs 15.1 difference ?

My compiler is g++ 4.8.

Bill P.

Post a reply to this message

Le 04/03/2016 19:41, William F Pokorny a écrit :
> On 03/04/2016 01:22 PM, clipka wrote:
>> Am 04.03.2016 um 19:01 schrieb Le_Forgeron:
>>> Le 04/03/2016 17:22, William F Pokorny a écrit :
>> ...
>>>> Same here. The patch disappears in 3.7.1-alpha.8499454 while it works in
3.7.0-stable.
>>>
>>> Testing 3.7.1-alpha.8503825.unofficial, the object is there, same as with stable
version.
>>
>> While I did my own testing with 3.7.1-alpha.8503825 as well, I'd be
>> quite surprised if any of the changes since alpha.8499454 had fixed it.
>> They appear to be as unrelated as I could possibly imagine.
>>
> Think you are correct. I just pulled and compiled 3.7.1-alpha.8503825 on seeing
Jérôme at a newer version, but still nothing (no ray patch intersections are found).
So maybe a 14.04 vs 15.1 difference ?
> 
> My compiler is g++ 4.8.
> 


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

Just ignore the syscall param write, the interesting parts seem to be in bezier.cpp


I presume even windows get the same problem if you have some auditing tools on it.

And using the same valgrind on the stable version: no such issue.


It's new, it's fresh, it's hidden and unreliable, due to the memory content.

Post a reply to this message

Attachments:
Download 'memcheck2.txt' (48 KB)

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