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

> does the .bak file already exist, and if so, is it either read-only or
otherwise
> locked ?

Yes, there was already a .bak file when I got the problems mentioned before.
I have tried removing the .bak file and reproducing the problem once again,
but I'm still not allowed to save the file, nor can POV create a new .bak
file (unless I haven't aborted parsing). The .bak file is not write
protected.

However, while POV cannot rename the file to .bak, I can edit the existing
.bak file from POV and save it.

Exiting POV seems to be the only way to get around the problem; closing the
.pov file after an aborted parse and re-opening it, I still can't save
changes to the file.

>what happens if you manually delete it ?

I can delete, move etc. the .bak file from Windows Explorer without
problems. However, I am not allowed to move or delete the .pov file until I
exit POV, as Windows claims it's in use, even though I've pressed 'Close'
with the file in POV. I suspect the problem may be an issue of closing the
.pov file when aborting the parse.

- Peter

Post a reply to this message

I am having a similar problem.  Aborting a parse on certain .pov files
(every one I have had problems with has called a macro...) can somehow lock
the file.  I get the unusal error "Failed to save file: operation completed
successfully".  It seems that many of the times I have had this problem the
status bar had read "Parsed 5002 tokens" for quite a while, but the clock
in the lower right corner continues to count.  This time when I tried to
replicate it, the last message was "Parse Error: Out of memory.  Cannot
allocate 156 bytes for pigment", but it still refuses to stop parsing.  I
have hit "the stop sign" several times.  It finally quit after almost
fifteen minutes.

My system is POV 3.6 under Windows XP Pro fully patched, AMD 2100+, 512MB
PC2700 Kingston Value Ram, ASUS A7N8X (Nforce 2) Motherboard, Radeon 7500LE
video.

I called a macro which I wrote which creates interesting fractal objects and
the higher the order, the more complex the object.  I bumped up the order
until it generates a couple million objects, and have this problem.  I was
having the same problem with much more reasonable renders, though.

Alex Wollangk

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Sounds like you're running out of memory and starting to swap.

Yup.  Actually, running out of memory, swapping, running out of swap space
and crashing.  That is fine and expected.  It was just that it then
wouldn't let me save the file giving me the error "Can't save file:
operation completed successfully" which is an extremely odd error.

Post a reply to this message

I've been having the same problem, but just so you know this problem also
occurs if there is a syntax error in a macro in the include file.

This means that the error occurs more frequently than it would otherwise- it
can't be prevented by simply avoiding stopping the render at parse time.
I'm having to restart POVray rather often as a result of this. It's just a
blessing that it opens and closes so quickly ;)

Cheers.

Post a reply to this message