bkoep Staff Lv 1
Thanks! Steps to reproduce are immensely helpful for tracking bugs, especially when there is so little info in the log files!
Thanks! Steps to reproduce are immensely helpful for tracking bugs, especially when there is so little info in the log files!
Just to be contrary, I am not getting a crash on 1514 on Win 10 devprev. I have tried both Cut And Wiggle Forever and Cut and Wiggle 1.5, on high, from a reset puzzle, and have not gotten any crashes. I do see lots of "[ ERROR ] No proper DoF can be found for these four atoms:" in the log.txt, but it just keep chugging along anyway.
Is it possible that resetting may change something which enables cut to be handled?
On the other hand Loci reset before testing and he still crashed. https://fold.it/portal/node/2005121
Running CW today. Went smoothly. Gained 100 points and then crashed with IRC error 5 again. Couldn't see what n= was equal to when it crashed. Or was it some random IRC fluctuation. Did not touch program, nor did I touch chat.
core.kinematics.AtomTree: [ ERROR ] No proper DoF can be found for these four atoms: 231-3, 232-1, 232-2, 232-3!
core.kinematics.AtomTree: [ ERROR ] No proper DoF can be found for these four atoms: 238-1, 238-2, 238-3, 239-1!
core.kinematics.AtomTree: [ ERROR ] No proper DoF can be found for these four atoms: 238-2, 238-3, 239-1, 239-2!
UNHANDLED EXCEPTION
1: RaiseException +98 bytes (no line)
2: alIsAuxiliaryEffectSlot +603490 bytes (no line)
3: alIsAuxiliaryEffectSlot +488837 bytes (no line)
4: alIsAuxiliaryEffectSlot +481468 bytes (no line)
5: library_main +7655517 bytes (no line)
6: library_main +34548826 bytes (no line)
7: library_main +34560090 bytes (no line)
8: library_main +31625622 bytes (no line)
9: library_main +31624719 bytes (no line)
10: library_main +5912680 bytes (no line)
11: library_main +5488976 bytes (no line)
12: library_main +5909420 bytes (no line)
13: library_main +370360 bytes (no line)
14: library_main +3409717 bytes (no line)
15: library_main +3410155 bytes (no line)
16: BaseThreadInitThunk +36 bytes (no line)
17: RtlGetAppContainerNamedObjectPath +311 bytes (no line)
18: RtlGetAppContainerNamedObjectPath +263 bytes (no line)
IRC::run error, code = 5, desc = Remote connection closed
Exiting IRC::run
Just as a recap, puzzle 1514 tends to crash on high wiggle power.
I've been trying various things, here are a few observations.
First, a few things we can cross off.
I don't think the IRC error 5 has anything to do with the crash, seems more likely it's just part of the client shutting down after an error.
Similarly, the DoF error messages are mostly harmless. They don't always appear, and you can crash even if they don't appear.
The only lines in log.txt that seem to matter are the unhandled exeception and the numbered lines that follow. The good part is that we seem to getting the exact same exception, which isn't always the case.
Next, there are some exceptions to the crashing. An older "V1" LWS recipe is running where newer "V2" Banded Worm recipes fail. And Susume didn't crash when she tried my procedure (see above).
I suspect the difference may have something to do with undo. Recipes which were adapted for sketchbook may be less crashy than similar recipes. The strategy of doing a quicksave, trying something, and doing a quickload if there's no gain, may help. Avoiding recentbest may also be beneficial.
(On the other hand, just doing a "w" wiggle can cause a crash in some cases, so these workarounds are not going to be 100%.)
On the setting side, adjusting the size of the undo graph and memory usage might be worthwhile. These settings are found under "Graph Properties" on the the Undo menu.
So far, setting memory usage to 0% in Undo -> Graph Properties seems to have eliminated the quick crashes on 1514 with high wiggle power.
I also have Max Graph Length set to 25 in Undo -> Graph Properties. That setting by itself didn't prevent the crashes. Perhaps the combination of Max Graph Length and Memory Usage is the ticket.
Setting Memory Usage to a higher percentage may also work. Previous feedback indicated 80% was a good value, but I haven't tried it on 1514. Zero percent is working well for me.
On my old 32-bit laptop, changing the Graph Properties does not prevent crashing on high wiggle power. This laptop is running an up-to-date version of Windows 10 Pro.
On my 64-bit systems (Win 10 Pro and Home), setting Memory Usage to 0% and Max Graph Length to 25 still seems to be the magic ticket to fixing 1514.
50% Graph Mem allocation does NOT work, that was my original settings. Working with your 0% settings now and all 8 clients are presently working. All computers using Crucial 1600L DDR3 16 GB except my 2 oldest desktops. BS ( band strength ) is NOT primary cause of this crash or dying clients. Devs, we need much better error handling on the clients, a truely good reason for a more complex client.