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