Folks,

The Linux source for 3.7 (currently marked beta 25b) is now available via
our beta source page, http://www.povray.org/beta/source/. Please be sure to
read the INSTALL included within the archive if you intend to build it.

regards,

-- Chris

Post a reply to this message

wonderful!  as soon as I get home, I'll try it out!

Post a reply to this message

oh, I got too excited that didn't even remember I have only 
single-core... :P

oh, well, the source may be entertaining enough!

Post a reply to this message

Hi,

already compiled it in a x86_64 GNU/Linux box, but still some bugs around.
Most critical one for me is that even tough I have 64G RAM and a 4 quad-core
Xeon, I get a "Fatal error in renderer: Out of memory." due to some problem
with interiors. Does anyone know about the status of this bug?

Anyway, SMP works perfectly!

Cheers

Post a reply to this message

"b-soain" <nomail@nomail> wrote:
> Most critical one for me is that even tough I have 64G RAM and a 4 quad-core
> Xeon, I get a "Fatal error in renderer: Out of memory." due to some problem
> with interiors. Does anyone know about the status of this bug?

I can't find a full, up-to-date list of known bugs. Perhaps the best thing to do
would be to start a new thread and post a minimal scene to show the problem.

Tom

Post a reply to this message

b-soain wrote:
> already compiled it in a x86_64 GNU/Linux box, but still some bugs around.
> Most critical one for me is that even tough I have 64G RAM and a 4 quad-core
> Xeon, I get a "Fatal error in renderer: Out of memory." due to some problem
> with interiors. Does anyone know about the status of this bug?

This is not a bug, it is an internal buffer that trades speed for memory 
limits. It should not be needed, but a better solution is complicated and 
time intensive to implement.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> This is not a bug, it is an internal buffer that trades speed for memory 
> limits. It should not be needed, but a better solution is complicated and 
> time intensive to implement.

  Could the reaching this limit be detected and a better error message be
shown? Now it looks just like a regular "out of memory" error while it
really isn't, as it's a particular special case. Perhaps a more informative
message could be better in this situation.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
>> This is not a bug, it is an internal buffer that trades speed for memory 
>> limits. It should not be needed, but a better solution is complicated and 
>> time intensive to implement.
> 
>   Could the reaching this limit be detected and a better error message be
> shown?

I said a better solution is possible, did I not? ;-)

	Thorsten

Post a reply to this message

b-soain wrote:
> already compiled it in a x86_64 GNU/Linux box, but still some bugs around.
> Most critical one for me is that even tough I have 64G RAM and a 4 quad-core
> Xeon, I get a "Fatal error in renderer: Out of memory." due to some problem
> with interiors. Does anyone know about the status of this bug?

Sample scene please?

Post a reply to this message

Not sure if this is the right location to post this...

I managed to get it compiled on a quadcore system running Fedora 8, though it
took a while to figure out that I had to configure with the option
"--with-boost-thread=boost_thread-mt"

Test render during compilation worked fine, but when I went to render some old
scenes I had laying around I would  get the message:
"Timed out waiting for worker thread startup"

If I keep running the command it will eventually work, but I generally get the
time out message instead of parsing and rendering.

I decided to try beta binary and got the same thing.

Seems like it should be something simple, but I don't know where to start.

SMP worked fine when it would actually render.

--paul

Post a reply to this message

Thorsten Froehlich nous apporta ses lumieres en ce 2008/02/28 05:23:
> Warp wrote:
>> Thorsten Froehlich <tho### [at] trfde> wrote:
>>> This is not a bug, it is an internal buffer that trades speed for 
>>> memory limits. It should not be needed, but a better solution is 
>>> complicated and time intensive to implement.
>>
>>   Could the reaching this limit be detected and a better error message be
>> shown?
> 
> I said a better solution is possible, did I not? ;-)
> 
>     Thorsten
> 
The error message should read "Buffer overflow", not "Out of memory".

-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when you can recite your high school 
Trig book from memory.

Post a reply to this message

Alain escribió:
> The error message should read "Buffer overflow", not "Out of memory".
> 

That will scare the hell out of users who know those two words related 
to security vulnerabilities.

Post a reply to this message

Nicolas Alvarez nous apporta ses lumieres en ce 2008/02/28 11:16:
> Alain escribió:
>> The error message should read "Buffer overflow", not "Out of memory".
>>
> 
> That will scare the hell out of users who know those two words related 
> to security vulnerabilities.
Undetected buffer overflow is bad. Detected ones or those that cause a process 
to abort are usualy not a problem.
Alternately, it could be "Work buffer full", or "Buffer fault".

-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when you can recite your high school 
Trig book from memory.

Post a reply to this message

Alain wrote:
> Nicolas Alvarez nous apporta ses lumieres en ce 2008/02/28 11:16:
>> Alain escribió:
>>> The error message should read "Buffer overflow", not "Out of memory".
>>>
>>
>> That will scare the hell out of users who know those two words related 
>> to security vulnerabilities.
> Undetected buffer overflow is bad. Detected ones or those that cause a 
> process to abort are usualy not a problem.
> Alternately, it could be "Work buffer full", or "Buffer fault".

It isn't a buffer overflow.

	Thorsten

Post a reply to this message

Alain escribió:
> Nicolas Alvarez nous apporta ses lumieres en ce 2008/02/28 11:16:
>> Alain escribió:
>>> The error message should read "Buffer overflow", not "Out of memory".
>>>
>>
>> That will scare the hell out of users who know those two words related 
>> to security vulnerabilities.
 >
> Undetected buffer overflow is bad. Detected ones or those that cause a 
> process to abort are usualy not a problem.
> Alternately, it could be "Work buffer full", or "Buffer fault".

*I* know that, but go explain it to naive users, who have "buffer 
overflow = security exploit" on their heads.

http://blogs.technet.com/markrussinovich/archive/2005/05/17/buffer-overflows.aspx

Also, the buffer didn't overflow. It reached a limit, and stopped there. 
So such a message would be incorrect anyway.

Post a reply to this message

> "Timed out waiting for worker thread startup"

	This indeed seems to happen on Fedora 8 and some current gentoo distro
at least.  Others such as Debian or Ubuntu usually work.  At the moment
I can't tell what might cause the problem, i.e. whether it has to do with
libc, boost, the system thread library or else  :-/

	- NC

Post a reply to this message

Nicolas Alvarez nous apporta ses lumieres en ce 2008/02/28 12:08:

> *I* know that, but go explain it to naive users, who have "buffer 
> overflow = security exploit" on their heads.
> 
> http://blogs.technet.com/markrussinovich/archive/2005/05/17/buffer-overflows.aspx 
> 
> 
> Also, the buffer didn't overflow. It reached a limit, and stopped there. 
> So such a message would be incorrect anyway.
So "Buffer full" or "Buffer limit reatched" would be a more correct message.

-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when you can recite your high school 
Trig book from memory.

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:
> So "Buffer full" or "Buffer limit reatched" would be a more correct message.

  The message should also say *which* buffer. That way the user can know
better what exactly is it in his scene that is causing the problem.

-- 
                                                          - Warp

Post a reply to this message

Le Thu, 28 Feb 2008 21:08:35 +0100, Nicolas Calimet a modifié des petits
morceaux de l'univers pour nous faire lire :

>> "Timed out waiting for worker thread startup"
> 
> 	This indeed seems to happen on Fedora 8 and some current gentoo 
distro
> at least.  Others such as Debian or Ubuntu usually work.  At the moment
> I can't tell what might cause the problem, i.e. whether it has to do
> with libc, boost, the system thread library or else  :-/
> 
> 	- NC

Yes. I confirm that.
I'm on gentoo amd64 (~amd64: unstable), and it looks like it can run once 
then fails.
Even invoking only "povray --version" does produce this issue: first time 
is ok, next are "Timed out".

My setting is

# ./configure COMPILED_BY=... --disable-io-restrictions
(... is a place holder)
# make check
# make install


Even adding --disable-optimiz-arch does not change the issue.

A reboot (it's a bit hard) allow one run.
I made a ps before first run, then after second (failed) run: no lagging 
process.

The trigger seems to be in vfesession.cpp vfeSession::Initialize

Might it be related to a resume state ?
Shouldn't this issue have it's own thread ?

even the sequence:
# ./configure ....
# make check
# make check

would trigger the issue.
Any suggestion how I could help ?

Post a reply to this message

Hi,
it is great to have the code, I enjoy playing around with it ;)
With my self-compiled pov-ray beta I keep getting errors like "Xlib: 
unexpected async reply (sequence 0x68)!". I suspect the reason is that 
POV calls SDL functions from different threads or from signal handlers. 
SDL's graphics functions are not thread-safe. I do not have this problem 
when I switch the display off.
I have not tried the official binary.
Regards,
Lukas

Post a reply to this message

Warp wrote:
> Alain <ele### [at] netscapenet> wrote:
>> So "Buffer full" or "Buffer limit reatched" would be a more correct message.
> 
>   The message should also say *which* buffer. That way the user can know
> better what exactly is it in his scene that is causing the problem.

I would tend to agree. Since the OP didn't post a sample scene or respond
to my request for one, I can't do much at this point, as I simply don't
know what part of the code is involved. It appears that others do know
this, though - could someone perhaps take the time to actually *tell* me
what part of the interior code in question this is? Or provide a scene so I
can find out myself?

-- Chris

Post a reply to this message

Chris Cason wrote:
> Warp wrote:
>> Alain <ele### [at] netscapenet> wrote:
>>> So "Buffer full" or "Buffer limit reatched" would be a more correct message.
>>   The message should also say *which* buffer. That way the user can know
>> better what exactly is it in his scene that is causing the problem.
> 
> I would tend to agree. Since the OP didn't post a sample scene or respond
> to my request for one, I can't do much at this point, as I simply don't
> know what part of the code is involved. It appears that others do know
> this, though - could someone perhaps take the time to actually *tell* me
> what part of the interior code in question this is? Or provide a scene so I
> can find out myself?

It comes from the fixed size vector code as far as I can guess.

	Thorsten

Post a reply to this message