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.
Attached to Project: POV-Ray
Opened by Christoph Lipka - 2011-04-12
Last edited by Christoph Lipka - 2012-06-21
Opened by Christoph Lipka - 2011-04-12
Last edited by Christoph Lipka - 2012-06-21
FS#201 - repeated re-declaring of functions causes runaway memory consumption
original posting from povray.beta-test:
I get this error message: "Parse Error: bad allocation Render failed" - after the code below has been running for about 3 seconds. // ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7 #version 3.7; #while (true) #local Fn = function { transform { translate <0, 0, 0> } } #undef Fn #end // while // ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7 I'm using POV-Ray for Windows - Version 3.7.0.RC3.msvc9-sse2.win32 The operating system is Windows XP. With the code above, the error messages has so far appeared every time right after 3318K tokens have been parsed. But with other versions of my code, the error message does not always show up. (Sometimes the render finishes and sometimes the parsing stops at different "times".) [...]
Other users report no error message, but memory consumption rising to about 1.2 GB.
Closed by Christoph Lipka
Thursday, 21 June 2012, 23:02 GMT
Reason for closing: Fixed
Additional comments about closing:
Thursday, 21 June 2012, 23:02 GMT
Reason for closing: Fixed
Additional comments about closing:
no news, so I guess the fix was
effective
Currently, POV-Ray allows a maximum of 1048575 functions per scene - including undef'd functions - before it starts reclaiming entries in a certain table currently occupied by already undef'd functions. Repeated declaring and undef'ing of functions therefore grows the table to about 1.2 GB or the system's memory limits, whatever comes first.
Apparently this was implemented with the intention of improving parsing speed of scenes declaring (but not undef'ing) lots of functions, to prevent having to search for reclaimable table entries in vain.
I'm currently working on a scheme that will allow fast lookup of reclaimable entries, so that searching for reclaimable entries can be preferred over growing the table, without any noticeable performance penalty.
fixed with change #5434