New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When the PDE crashes, the preference for the sketchbook location reverts back to the default path directory #4614

Closed
jshaw opened this Issue Aug 13, 2016 · 7 comments

Comments

Projects
None yet
3 participants
@jshaw

jshaw commented Aug 13, 2016

I have my Processing3 sketchbook location set to path/Documents/Processing3/ to help maintain older processing projects that I am still maintaining. However, whenever the Processing3 PDE crashes it reverts the sketchbook location in it's preferences back to the path/Documents/Processing/ path, the default.

It would be nice if after the crash the preferences were persistent with the current install of the PDE.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Aug 13, 2016

Member

Crashes how? It should only take one successful write of the preferences to make that preference stick. That is, if you run Processing once and quit (without crashing), there's no way this should reset.

If you're crashing on every run, the preferences file will never get a chance to write, but that'd be pretty weird.

Member

benfry commented Aug 13, 2016

Crashes how? It should only take one successful write of the preferences to make that preference stick. That is, if you run Processing once and quit (without crashing), there's no way this should reset.

If you're crashing on every run, the preferences file will never get a chance to write, but that'd be pretty weird.

@jshaw

This comment has been minimized.

Show comment
Hide comment
@jshaw

jshaw Aug 13, 2016

Sorry if there wasn't enough context. An explanation of how I am getting the crash is below. If i run the PDE and change / update the sketchbook location to path/Documents/Processing3 and run a sketch that I know doesn't have any issues and then close the PDE I don't get any issues. The next time I open the PDE the sketchbook path is persistent.

Currently, I'm working on visualizing distance measurements taken from a loaded 2D array that has roughly ~30 X 300 (9,000) measurements being represented in a 3d mesh. I am thinking there's probably a way I can improve how I'm rendering the code but on times when the PDE either times out or freezes due to, what I think is computation complexity, I have to Force Restart the sketch and the PDE and it is on the force restart that the sketchbook location reverts back to the default.

I am also using PeasyCam for 3d rotation around the generated mesh. Without PeasyCam rotation the PDE doesn't crash as often, however the issue i'm reporting isn't PeasyCam causing the crashing but that when a crash happens the sketchbook location reverts to default.

Hope this helps a bit more. If there's any more info or code samples I can share or provide let me know :)

jshaw commented Aug 13, 2016

Sorry if there wasn't enough context. An explanation of how I am getting the crash is below. If i run the PDE and change / update the sketchbook location to path/Documents/Processing3 and run a sketch that I know doesn't have any issues and then close the PDE I don't get any issues. The next time I open the PDE the sketchbook path is persistent.

Currently, I'm working on visualizing distance measurements taken from a loaded 2D array that has roughly ~30 X 300 (9,000) measurements being represented in a 3d mesh. I am thinking there's probably a way I can improve how I'm rendering the code but on times when the PDE either times out or freezes due to, what I think is computation complexity, I have to Force Restart the sketch and the PDE and it is on the force restart that the sketchbook location reverts back to the default.

I am also using PeasyCam for 3d rotation around the generated mesh. Without PeasyCam rotation the PDE doesn't crash as often, however the issue i'm reporting isn't PeasyCam causing the crashing but that when a crash happens the sketchbook location reverts to default.

Hope this helps a bit more. If there's any more info or code samples I can share or provide let me know :)

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Aug 13, 2016

Member

If you can make it crash consistently, can you do that, and before starting Processing again, make a copy of your preferences.txt file and post it here? I'd like to see if it's going corrupt somehow. It should be saving your new sketchbook preference right after you set it, so I'm not sure why it would reset like this.

Member

benfry commented Aug 13, 2016

If you can make it crash consistently, can you do that, and before starting Processing again, make a copy of your preferences.txt file and post it here? I'd like to see if it's going corrupt somehow. It should be saving your new sketchbook preference right after you set it, so I'm not sure why it would reset like this.

@jshaw

This comment has been minimized.

Show comment
Hide comment
@jshaw

jshaw Aug 13, 2016

Hey, Yep, I was able to reproduce the crash. To re-create the issue I just ramped up the number of vertices i was going to include in my mesh and it seems as though it times out or doesn't finish rendering the mesh. The sketch just displays blank. I have to let the sketch run for about a minute or so while it does its thing. I was able to close the sketch with the "x" close button in the sketch window and I could close the PDE window however the Processing app still had the dot under it in my dock (I'm using osx). I tried to close the Processing app in the dock but that wasn't doing anything so I have to force quite the Processing app.

I've attached three preferences.txt files, a customized one from before the crash, the crashed one and the one generated on restart. It looks like the crash is clearing the preferences.txt file completely. Because the file seems to be empty I can't upload it in the comment section so I've uploaded to my dropbox and provided the link to the file.

Cheers,

preferences_custom.txt

preferences_crash.txt

preferences_restart_pde.txt

jshaw commented Aug 13, 2016

Hey, Yep, I was able to reproduce the crash. To re-create the issue I just ramped up the number of vertices i was going to include in my mesh and it seems as though it times out or doesn't finish rendering the mesh. The sketch just displays blank. I have to let the sketch run for about a minute or so while it does its thing. I was able to close the sketch with the "x" close button in the sketch window and I could close the PDE window however the Processing app still had the dot under it in my dock (I'm using osx). I tried to close the Processing app in the dock but that wasn't doing anything so I have to force quite the Processing app.

I've attached three preferences.txt files, a customized one from before the crash, the crashed one and the one generated on restart. It looks like the crash is clearing the preferences.txt file completely. Because the file seems to be empty I can't upload it in the comment section so I've uploaded to my dropbox and provided the link to the file.

Cheers,

preferences_custom.txt

preferences_crash.txt

preferences_restart_pde.txt

@benfry benfry closed this in 4207712 Aug 13, 2016

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Aug 13, 2016

Member

Ok, the next release (3.2) should have a fix. The preferences file was being written directly, rather than first writing to a temporary file, and replacing the original preferences.txt only after the file had finished writing successfully. Not great practice, so hopefully fixing that will take care of things.

Member

benfry commented Aug 13, 2016

Ok, the next release (3.2) should have a fix. The preferences file was being written directly, rather than first writing to a temporary file, and replacing the original preferences.txt only after the file had finished writing successfully. Not great practice, so hopefully fixing that will take care of things.

@mxmlnkn

This comment has been minimized.

Show comment
Hide comment
@mxmlnkn

mxmlnkn Aug 18, 2016

When installing processing 3.2. and starting it for the first time, I get:

java.io.IOException: Could not replace preferences.old
    at processing.app.Preferences.save(Preferences.java:237)
    at processing.app.Preferences.init(Preferences.java:106)
    at processing.app.Base.createAndShowGUI(Base.java:154)
    at processing.app.Base.access$0(Base.java:125)
    at processing.app.Base$1.run(Base.java:114)
    at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
    at java.awt.EventQueue.access$500(EventQueue.java:97)
    at java.awt.EventQueue$3.run(EventQueue.java:709)
    at java.awt.EventQueue$3.run(EventQueue.java:703)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

When using 3.1.1 I don't get such an error, moreover when starting 3.2 after a successful start 3.2 also works. Removing ~/.processing/ makes the error reappear in 3.2, though.

I have several reasons to think that it is related to this issue.

mxmlnkn commented Aug 18, 2016

When installing processing 3.2. and starting it for the first time, I get:

java.io.IOException: Could not replace preferences.old
    at processing.app.Preferences.save(Preferences.java:237)
    at processing.app.Preferences.init(Preferences.java:106)
    at processing.app.Base.createAndShowGUI(Base.java:154)
    at processing.app.Base.access$0(Base.java:125)
    at processing.app.Base$1.run(Base.java:114)
    at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
    at java.awt.EventQueue.access$500(EventQueue.java:97)
    at java.awt.EventQueue$3.run(EventQueue.java:709)
    at java.awt.EventQueue$3.run(EventQueue.java:703)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

When using 3.1.1 I don't get such an error, moreover when starting 3.2 after a successful start 3.2 also works. Removing ~/.processing/ makes the error reappear in 3.2, though.

I have several reasons to think that it is related to this issue.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Aug 18, 2016

Member

That's a new bug; now filed here: #4626

Member

benfry commented Aug 18, 2016

That's a new bug; now filed here: #4626

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment