On 9/26/19 12:13 PM, Jörg "Yadgar" Bleimann wrote:
> Hi(gh)!
> 
> Strangely enough, it worked fine with POV-Ray 3.7 under Windows 7 on the 
> same machine... so it's probably more likely a software (i. e. POV-Ray 
> 3.7.0unofficial for Linux) than a hardware issue!
> 

This sounds like our old thread stack size issue where jobs would run on 
windows with a given allocation size and not on unix builds. Not sure we 
ever nailed down whether the windows compile was handling the stack 
overruns (by allocating more memory as needed) or if unix compiles 
needed more memory for some reason. As a patch, there was an initial 
macro implementation in v38 where one could set a larger allocation 
during the POV-Ray compile. Christoph later replaced it with a method 
based upon thread local storage and std::vector which, while a tiny bit 
slower, fixed all the storage overruns we'd seen. More memory is 
allocated if need be until you run out it instead of there being a fixed 
compile time set limit of memory for each thread's stack...

Long winded way to say using the current v38 branch might well fix your 
problem.

> Yes, I load between 125,000 and 300,000 one-pixel PNGs, each of them not 
> larger than 90 bytes... what is "freed on redef"? Explain!
> 

The slang was just me thinking aloud. When you declare again each pixel 
pigment { image_map .... } with the same ID/Name, it should be the 
memory used for the previous image_map is freed.

> 
>  > Are you able to run a linux command like top in an xterm - or a fancier
>  > system monitor as your job runs?
> 
> Yes, that works!
> 
>   A command line like time (on Ubuntu at
>  > /usr/bin/time) which can be used like:
> I'm not using Ubuntu, but rather Debian 8.11 (oldoldstable)!
> 

Ubuntu is based upon Debian so you probably have the /usr/bin.time 
command too. Note. If you are in a bash shell/xterm the shell itself has 
a 'time' command which isn't the same as the fully specified 
/usr/bin/time command. Using \time is another way to use /usr/bin/time 
over bash's time which should work. Yep, messy.

Being back on Debian 8.11 might mean you cannot compile the current v38 
master branch. I don't know what gnu/clang compiler versions it supports.

> 
>  > If you are able to run it sometimes, does it run when you have fewer
>  > frames or some other specific conditions. Might give a clue.
> 
> I did not try this yet... but I will soon as I also want to process some 
> shorter videos!
> See you in Khyberspace!
> 
> Yadgar

Let us know what you find.

Bill P.

Post a reply to this message