On 5/9/23 09:14, Cousin Ricky wrote:
> The following scene crashes with the error:
> 
>    line 4: Parse Error: std::bad_alloc
> 
> ----------[BEGIN CODE]----------
> #version max (3.5, min (3.8, version));
> global_settings { assumed_gamma 1 }
> #declare Int = interior { ior 1.5 }
> #declare myInt = Int
> -----------[END CODE]-----------
> 
> The discontinued 3.7.1-rc.1 also crashes, but previous versions of
> POV-Ray do not.
> 
> POV-Ray version: POV-Ray 3.8.0-beta.2 (self-compiled)
> Operating system: openSUSE Leap 15.3 GNU/Linux
> Hardware: Lenovo Ideapad Slim 7
> CPU: Intel Core i7

Thanks Cousin Ricky and Kenneth and jr for confirmations and tests with 
other shapes. I've been looking at this, but will be away for a while 
starting later today.

So, an update.

At the bottom the issue here seems to be that the first created interior 
gets deleted before the copy in the symbol table code. There was an 
attempt to move to smart pointers on removing the reference counting in 
v3.7, and something went wrong there. I just cannot yet see it - or how 
I might patch it.

The form and feel of this bug rings a bell. There was some other bug 
recently due a similar move from reference counting to smart pointers 
that I patched by creating a local copy of something to itself be what 
was really copied because the original smart pointer controlled to be 
copied version was going poof too quickly.

Bill P.

---
More for those interested.

a) What I suspect here and with that other bug (I can't completely 
remember at the moment...) is that thinking a smart pointer can always 
simply replace reference counting method is dangerous.

I believe what's happening is the reference counting previous had 
different in timing with respect to when some allocated thing was 
'counted' as no longer referenced then deleted than the scope based auto 
magic happening with smart pointers to do the reference tracking and 
deletion. I think the latter tends to clean up faster.


b) There is on top of the issue above another in that the template 
function introduced in the symbol table code depends on there being a 
valid form of an = type object copy. There was none.

Someone had added an explicit bit of C++ preventing an '=' overload for 
the copy. I don't know why. I cannot see a reason for it.

So, I fixed things so there was a proper = overload as there is with 
some other things (media, camera..) using the same template id copying 
function in the symbol table code. But, the core issue was still there - 
which didn't surprise me too much.

And why was that? Well in a happy world where C++ helps you, the 
compiler would have just died on not finding the matching '=' copy. The 
lack of the '=' copy was just something I noticed. My, unconfirmed, 
suspicion is all the casting to void pointers happening within that 
template function, bypassed the C++ feature preventing the original '=' 
sort of object copy of interiors.

Anyhow. No idea when I'll get back to this. The free time I'll have in 
the coming weeks amounts to small run fragments.

Post a reply to this message