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

Post a reply to this message

[in Windows 10, running official v3.8.0 beta 1, Lenovo desktop machine, Core i7]

These first 3 lines run OK...

#version max (3.5, min (3.8, version));
global_settings { assumed_gamma 1 }
#declare Int = interior { ior 1.5 }

Adding the 4th line...
      #declare myInt = Int
...causes a fatal error-- but the error message changes(!)

If I freshly start POV-ray, the error says
       "Parse error: vector <T> to long"  (whatever that means).

Immediately running the code again, it's
      "Parse error: bad allocation"

By changing the 4th line to
      #declare myInt = interior{Int}
it all runs fine, no error.

Post a reply to this message

I just tried a similar construct using a pigment instead of an interior--
thinking that the same error might occur...

#version max (3.5, min (3.8, version));
global_settings { assumed_gamma 1 }
#declare PIG = pigment{bozo}
#declare myPIG = PIG

... but that runs OK! So it seems that the problem might be exclusive to the
'interior' block... or ior... ?

Post a reply to this message

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> The following scene crashes with the error:
> ...
> POV-Ray version: POV-Ray 3.8.0-beta.2 (self-compiled)

same for self-compiled 3.8.0-alpha.9945627.


regards, jr.

Post a reply to this message

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

William F Pokorny <ano### [at] anonymousorg> wrote:

> 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.

Yeah - I vaguely recall that too.  Was it with the heightfield stuff?

Post a reply to this message

On 5/11/23 07:49, William F Pokorny wrote:
> 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.

I've spent a little more time on this and I don't currently see a clean 
way to fix this issue. Well, other than returning to a plain pointer and 
reference counting as in v3.7 (and v3.8 to some point during development).

Given how the parser is set up, v3.8 is running smart, shared, interior 
pointers through casts to a void pointer and back to a shared pointers.

Pending an actual fix, I strongly recommend v3.8 add a throw in 
symboltable.cpp just after the switch "case INTERIOR_ID_TOKEN:". 
Something like:

throw POV_EXCEPTION_STRING("Interior ID = ID copies broken in v3.8");

While likely the garbage in memory pointed to after the attempted 
interior ID copy will stink enough to crash code somewhere within 
POV-Ray(a), a scene with such a copy could 'execute' without a crash - 
if one is unlucky.

Bill P.

(a) - It's not the actual copy which crashes, but some later operation 
on garbage data.

Post a reply to this message