The Persistence of Vision Raytracer (POV-Ray).

This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.


FS#257 - POV-Ray cannot find input file when resuming to render the 25th frame

Attached to Project: POV-Ray
Opened by Casper Ti. Vector (CasperVector) - Monday, 22 October 2012, 10:15 GMT
Last edited by Thorsten Fröhlich (thorsten) - Monday, 25 March 2013, 08:03 GMT
Task Type Definite Bug
Category Frontend → Other
Status Closed
Assigned To Thorsten Fröhlich (thorsten)
Operating System All
Severity Low
Priority Normal
Reported Version 3.70 RC6
Due in Version 3.70 RC7
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


How to reproduce:

# An empty directory, an empty source file.
$ mkdir test && cd test && touch test.pov
# Generate the first 24 frames.
$ povray -D +KFF24 +Itest.pov +Otest.png
# Try to generate the 25th frame.
# `25' after `+KFF' can be changed to any integer greater than 24.
$ povray -D +C +KFF25 +Itest.pov +Otest.png

What happens:

==== [Parsing...] ==========================================================
Possible Parse Error: Cannot find file 'test.pov', even after trying to append
 file type extension.
Parse Error: Cannot open input file.
Fatal error in parser: Cannot parse input.
Render failed

OS: Gentoo AMD64 unstable
POV-Ray version: 3.7.0 rc5

This task depends upon

Closed by  Thorsten Fröhlich (thorsten)
Monday, 25 March 2013, 08:03 GMT
Reason for closing:  Fixed
Comment by Casper Ti. Vector (CasperVector) - Monday, 22 October 2012, 10:18 GMT

Hmm, to avoid possible confusion, I emphasise that my POV-Ray version is 3.7.0 rc5, not rc6, and that is because Gentoo does not provide rc6 for now.

Comment by Grimbert Jérôme (Le_Forgeron) - Monday, 22 October 2012, 17:01 GMT


tested with 3.7RC6+ (latest generation from 7 October 2012), the problem does not occurs.
tested with 3.7RC6 too, and the problem does not occurs either.

I would have said it could have been corrected with  FS#217 , but that was already ok with 3.7RC5;

Nevertheless, the issue seems gone in 3.7RC6.

As you are using gentoo, you are normally an adept of compiling things yourself: why not give the official tarball of 3.7RC6 a try ?
(yes, it is a bit more complex than "emerge..." but as you installed everything needed already, you just need the tarball and run the configure in it, it should work)

Comment by Casper Ti. Vector (CasperVector) - Tuesday, 23 October 2012, 02:31 GMT

Sad to say, this persists in 3.7RC6...
The "magic" frame number does not change, and is still 25.

Comment by Grimbert Jérôme (Le_Forgeron) - Tuesday, 23 October 2012, 20:20 GMT

Confirmed with 3.7RC6 (in debug mode, without io restrictions), with the last invocation being:

valgrind –log-file=myleak –leak-check=full –show-reachable=yes –track-origins=yes –malloc-fill=C8 –free-fill=42 $TITI/povray -D +C +KFF25 +Itest.pov +Otest.png

Rendering frame 2 of 25

Parser Options

Input file: test.pov
Remove bounds........On 
Split unions.........Off
Library paths:

Animation Options

Initial Frame:        1  Final Frame:       25
Frame Step:           1
Initial Clock:    0.000  Final Clock:    0.000
Cyclic Animation.....Off  Field render.........Off  Odd lines/frames.....Off

Image Output Options

Image resolution.....800 by 600 (rows 1 to 600, columns 1 to 800).
Output file..........test02.png, 24 bpp PNG
Graphic display......Off
Mosaic preview.......Off
Continued trace......On 

Information Output Options

All Streams to console..........On 
Debug Stream to console.........On 
Fatal Stream to console.........On 
Render Stream to console........On 
Statistics Stream to console....On 
Warning Stream to console.......On 

Possible Parse Error: Cannot find file 'test.pov', even after trying to append
file type extension.
Parse Error: Cannot open input file.
Fatal error in parser: Cannot parse input.
Render failed

It's not on frame 25, but already at frame 2.. with continue.
Looks like  FS#217  is to be reopened, or it could also be kept investigating here.

   myleak (6.9 KiB)
Comment by Casper Ti. Vector (CasperVector) - Wednesday, 24 October 2012, 01:13 GMT

Yeah, so it seems that the "magic" number varies between machines...

Comment by Grimbert Jérôme (Le_Forgeron) - Sunday, 28 October 2012, 16:09 GMT

Work in progress (but additional lights are welcome): it seems that the issue is due to the map<SceneId, SceneHandler>
SceneId is a composite made of an Identifier and an Address.

When image is found existing (#1), the scene is not closed ( ? huh ? : no call to void RenderFrontend<PARSER_MH, FILE_MH, RENDER_MH, IMAGE_MH>::CloseScene(SceneId sid) )

So scenehandler grows for the next scene... unless the SceneId object get the same pointer (which it does if the stack of functions call is identical... bad luck). The declaration of scenehandler does not change the compare function, nor the allocator (? doubtful, but I'm not good enough with map<> with a structure/class as key )

The compare function default to the operator< ... of Id, which seems not consistent enough for a global order:

bool operator<(const Id& o) const { return ((address < o.address) && (identifier < o.identifier)); }

When address & identifier gives a different order, map might be dead (map usual implementation uses a BST, which can only works with strong order of key). (there is only a "less" operator in map, no == of key, the == can be detected with a double false on A1 < A2 and A2 < A1))

In my experiment,
scene #1 got address 0x2b85ac000930 , with address of scene-Id 0x2b859eaaf930
scene #2 got address 0x2b85ac000930 , with address of scene-Id 0x2b859eaaf930

#1 < #2 : false (same address)
#2 < #1 : false (opposite identifier's order, 2 is not less than 1)
So, same key, and the CreateScene() changes the value part, but there is no need to update the key (as they are identical, from map<> point of view). When we come back for Id 2, we do not find it.

The relevant code is in renderfrontend.h (source/frontend)

Closing the scene when it was already rendered might hide the issue with the map. (Why is there more than one active scene at a time, hence the need for scenehandler[], I have no clue)

Any hints ? clue ? recommendations ?
(edited to get away with the footnote flyspray syntax at operator quote)

Comment by Thorsten Fröhlich (thorsten) - Monday, 29 October 2012, 01:37 GMT

I will take a look at it, unless you find the problem first: The issue is not in RenderFrontend, the issue is in the calling code. It deletes a pointer owned by RenderFrontend behind its back, causing the malfunction (the delete being implicit if its on the stack, of course). So you are right, a call to CloseScene is missing somewhere.

As for your question: Yes, it is technically possible to have more than one scene at a time.

Comment by Thorsten Fröhlich (thorsten) - Monday, 29 October 2012, 02:35 GMT

A few corrections here: SceneHandler is not a pointer. The comparison function is not part of the map, it is part of the key class, which is RenderFrontendBase:Id.

I am not sure where you are getting the code "bool operator<(const Id& o) const { return 1); }" from, but then again I cant sync to the most recent copy on Perforce from where I am. The correct code should be "bool operator<(const Id& o) const { return ((address < o.address) && (identifier < o.identifier)); }".

Maybe you could put your problem description together in a more structured order? It is very difficult to follow your post and what you want to say, as looking at the code contradicts what you are saying, and the information you provide is mostly out of context... :-(

At minimum I need to know what you are seeing in RenderFrontend::CreateScene, in particular the values of "backendaddress" and " sid", and the calls to RenderFrontend::CloseScene and the "sid" passed to it. This information needs to be seen in exact order of calls. And most important, if there is an exception coming somewhere that destroys these functions order - to me if anything the line "catch(pov_base::Exception&)" in RenderFrontend::CreateScene seems bogus. This should be a generic catch, not a specialized one as it needs to catch out of memory cases, which are not of type pov_base::Exception.

Comment by Grimbert Jérôme (Le_Forgeron) - Monday, 29 October 2012, 18:40 GMT

You are correct.

1. The map use the operator< from the key type; Here the only one is in the base class.
2. I'm a victim of flyspray autosyntax (and I did not use preview): it changed my quote of code into a footnote.
3. Sorry, I was exploring too many tracks at once, live.
4. I attached two logs (one for an empty, ok render; and another for the failing continue);

the line "Create Scene : " dumps the identifier / the size of the map on entry

The address of the scene is on the line above, "—– Scene created —"

The line "Create Scene # " dumps the address of the passed sid # the identifier / the size of the map after affectation

The big numbers, when not in hex, are usually thread id (Oh joy of multithreading and message passing)

Best regards.

Comment by Grimbert Jérôme (Le_Forgeron) - Thursday, 01 November 2012, 08:16 GMT


found and fixed with #5724.

Thanks for the clarifications.