POV-Ray

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.

Hello,

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)

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

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:
  /usr/local/share/povray-3.7
  /usr/local/share/povray-3.7/ini
  /usr/local/share/povray-3.7/include
  /home/jerome/police/Fonts

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
Dithering............Off
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)

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

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)

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.

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.

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.

   initial.txt (60.8 KiB)
   failure.txt (16.6 KiB)

Greetings,

found and fixed with #5724.

Thanks for the clarifications.