Hi,

This thread probably belongs in povray.windows.

That being said, I can't replicate the problem either. If I can you can be
sure it will be fixed but at this point I'm not seeing it.

Thorsten, I wonder if this is another example of non-volatile variables causing
problems ? e.g. I could never replicate that 'thread failed to init' problem
either but I know it affected certain machines but not others, just like this
one does.

If so a VC++ compile will probably flush it out.

-- Chris

Post a reply to this message

In article <40fddf29@news.povray.org> , "Chris Cason" 
<new### [at] deletethispovrayorg> wrote:

> Thorsten, I wonder if this is another example of non-volatile variables
causing
> problems ? e.g. I could never replicate that 'thread failed to init' problem
> either but I know it affected certain machines but not others, just like this
> one does.

I rather suspect it is a race condition somewhere.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> I'm sorry that doesn't help you.  Like the others, I'm running XP Home
with
> I/O permissions turned off.  As far as I can tell from previous posts,
this
> is the common theme.

I have had the problem using Windows ME, but so far any attempt to replicate
the problem has failed.

Peter

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:40fd5fcf$1@news.povray.org...
>
> I tried the "Tierra (LOTW)" scene posted in p.b.s-f a few weeks ago and
used
> it with 30000 trees and let it parse to 50 million tokens, then used the
> keybord to stop the render and instantly after that save the modified
scene
> file (in which I had inserted a space).  The files was saved as expected.
> The system was a P4 3GHz with 1 GB of memory running Win XP Pro (used over
> remote desktop) with all available Win patches installed.

I generally use the "Stop Sign" button, if that's at all relevant.

When you say you stopped "the render", do you actually mean "the parse"?

Again, as others have mentioned this does not appear to happen every time.
You could try your test at various intervals during the parse, and after
perhaps 10 or 20 times, see if it eventually causes the problem.

>
> Thus, I am afraid more information is needed.  A scene for example.  And
the
> system software, processor and physical memory of everone seeing this
> problem will surely not hurt either.

XP Home with all critical updates, AMD XP 3200+, 1GB RAM.  I can retest
after making sure that I have ALL XP updates.

>
> > Although I'm pretty sure you guys already know of this kind of
behaviour, I
> > still hope I'm at least helping a bit with this!
>
> Well, I think you have been told numerous times that this is not the case.

This problem was first mentioned on June 16th.

> And given that there is no flood of reports in these groups despite
> thousands of download, it should be fairly clear that this only happens on
> some systems...
>

This may be an underestimate.  The fact that a few regular posters to this
newsgroup have reported this problem likely means that a great deal more
people are having this problem and are simply not reporting it.

I'm willing to try anything that you can suggest to narrow this down, but
right now it appears to be completely random.

-- 
Jeremy
www.beantoad.com

Post a reply to this message

In article <40fec516$1@news.povray.org> , "Jeremy M. Praay" 
<jer### [at] questsoftwarecom> wrote:

>> I tried the "Tierra (LOTW)" scene posted in p.b.s-f a few weeks ago and
> used
>> it with 30000 trees and let it parse to 50 million tokens, then used the
>> keybord to stop the render and instantly after that save the modified
> scene
>> file (in which I had inserted a space).  The files was saved as expected.
>> The system was a P4 3GHz with 1 GB of memory running Win XP Pro (used over
>> remote desktop) with all available Win patches installed.
>
> I generally use the "Stop Sign" button, if that's at all relevant.
>
> When you say you stopped "the render", do you actually mean "the parse"?

Well, yes, the parse, of course :-)

> Again, as others have mentioned this does not appear to happen every time.
> You could try your test at various intervals during the parse, and after
> perhaps 10 or 20 times, see if it eventually causes the problem.

I tried several times, and other scenes as well.  It was suggested to
reproduce it, stopping a "long" parse would be required.  So I only stated
the longest I tried.

>> Well, I think you have been told numerous times that this is not the case.
>
> This problem was first mentioned on June 16th.

There was nothing specific in any of the reports so far allowing to
reproduce the problem.  As stated in the faq group, we only can say
something about confirmed bugs.  If we were to take every bug report
serious, especially but not limited to Windows, we would soon be fixing the
systems of everybody around, randing from removing viruses to replacing
defective RAM.  Thus, a single unconfirmed report that cannot be rpeproduced
is exactly as if the problem was never reported.

>> And given that there is no flood of reports in these groups despite
>> thousands of download, it should be fairly clear that this only happens on
>> some systems...
>
> This may be an underestimate.  The fact that a few regular posters to this
> newsgroup have reported this problem likely means that a great deal more
> people are having this problem and are simply not reporting it.

It certainly is not.  There was a several month long public beta test of
POV-Ray, and none of the beta testers reported this particular problem
either.  Yet, many other problems were reported and fixed.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Hi there,

I encounter similar problems trying to save modifications to files in
POV-Ray after aborting during parsing. I am running POV-Ray version
3.6.0.icl8.win32 under Windows XP Professional (SP1); hardware: 2.6 GHz P4,
512 MB RAM.

I have a scene file which seems to cause this error consistently if POV is
aborted during parsing. The error is produced this way:
* pressing 'Run' (or Alt+G) with the scene file in question;
* aborting while parsing (just 1 second of parsing should be sufficient to
reproduce it, but aborting during the rendering itself or letting the render
finish does not pose any problems at all);
* making a change to the .pov file (try adding a small comment, for
example);
* trying to save the .pov file afterwards (at any time until I exit POV, it
seems).

Trying to press 'Save', POV-Ray displays this message:

POV-Ray Editor
EAccessViolation: EAccessViolation

In this case, POV also fails to rename the original file to .bak. Upon
exiting POV, if I choose to save my changes, Windows tells me that POV has
crashed and the changes are not saved (choosing to discard the changes,
things are just fine). It affects only the .pov file in question; I can save
changes to other files without problems.

I can still use 'Save As...' with the .pov file in question, but trying to
save it with the original name still yields the 'EAccessViolation' error.

I have tried re-downloading and reinstalling POV 3.6, which didn't help the
problem. I wasn't able to reproduce the problem with POV 3.5.

The scene file uses an include file with a macro for outlining a mesh. The
macro uses 1D arrays quite extensively; I'll be posting the scene and
include file in povray.binaries.scene-files shortly.

- Peter

"RTRT buff" <tom### [at] yahoocom> skrev i en meddelelse
news:40fa5904@news.povray.org...
> run POV 3.6 on win XP
> failing to save file "<filename here>"
>
> some thing else using file???
>
> just before rendering
>
>
>

Post a reply to this message

In article <40fef90b$1@news.povray.org> , "Peter Svendsen" 
<pel### [at] hotmailcom> wrote:

> Hi there,
>
> I encounter similar problems trying to save modifications to files in
> POV-Ray after aborting during parsing. I am running POV-Ray version
> 3.6.0.icl8.win32 under Windows XP Professional (SP1); hardware: 2.6 GHz P4,
> 512 MB RAM.
>
> I have a scene file which seems to cause this error consistently if POV is
> aborted during parsing. The error is produced this way:
> * pressing 'Run' (or Alt+G) with the scene file in question;
> * aborting while parsing (just 1 second of parsing should be sufficient to
> reproduce it, but aborting during the rendering itself or letting the render
> finish does not pose any problems at all);
> * making a change to the .pov file (try adding a small comment, for
> example);
> * trying to save the .pov file afterwards (at any time until I exit POV, it
> seems).
>
> Trying to press 'Save', POV-Ray displays this message:
>
> POV-Ray Editor
> EAccessViolation: EAccessViolation
>
> In this case, POV also fails to rename the original file to .bak. Upon
> exiting POV, if I choose to save my changes, Windows tells me that POV has
> crashed and the changes are not saved (choosing to discard the changes,
> things are just fine). It affects only the .pov file in question; I can save
> changes to other files without problems.
>
> I can still use 'Save As...' with the .pov file in question, but trying to
> save it with the original name still yields the 'EAccessViolation' error.
>
> I have tried re-downloading and reinstalling POV 3.6, which didn't help the
> problem. I wasn't able to reproduce the problem with POV 3.5.
>
> The scene file uses an include file with a macro for outlining a mesh. The
> macro uses 1D arrays quite extensively; I'll be posting the scene and
> include file in povray.binaries.scene-files shortly.

Thank you very much!  I have now been able to reproduce your problem.  We
are going to look into it.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> Again, as others have mentioned this does not appear to happen every time.
> You could try your test at various intervals during the parse, and after
> perhaps 10 or 20 times, see if it eventually causes the problem.

In case it helps folks understand things, the way the software works is this:
when you ask the parse/render to stop, the front-end sends a message to the
back-end asking it to stop. Until it stops the input file will remain locked
(if the parse hasn't ended, that is).

For some reason on some occasions the back-end isn't stopping the parse when
asked.

The front-end keeps track of the stop request and if you enter another one and
the previous one hasn't yet been honored, it stamps down a lot harder on the
back-end and abruptly terminates it. This is why a second stop request often
makes a difference.

As for why it's not stopping, well, we'll have to find that ...

Post a reply to this message

> It certainly is not.  There was a several month long public beta test of
> POV-Ray, and none of the beta testers reported this particular problem
> either.  Yet, many other problems were reported and fixed.

to be fair to the OP, the 'backend thread failed to init' problem only
briefly emerged during testing (but then went away). Yet it came back with
a vengance after release. given not a lot of users end up in these groups,
it could be some just try and either put up with it, or simply give up.

I personally tend to agree that this problem is probably more widespread
than we in the team currently think.

-- Chris

Post a reply to this message

> In this case, POV also fails to rename the original file to .bak.

does the .bak file already exist, and if so, is it either read-only or otherwise
locked ? what happens if you manually delete it ?

-- Chris

Post a reply to this message