DevPrev crashes

[Bruno Kestemont]

Same crach on devprev Windows 7 RAM8 about 75% memory, about 75% CPU.
(running Main on other clients)

Devprev:

Toggle all
wiggle all
run filters
crash
(on 2 puzzles).

I shared to scientist: "Crash debvrev" of puzzle 1862

[bkoep]

Bruno, it looks like this log file comes from a main (non-devprev) client. Can you double check the Build ID for this client (in General Options)?

The devprev update is supposed to fix the "Run Filters" crash, so it is strange that you're still seeing the crash in devprev.

[bkoep]

There is definitely a problem with options not being saved correctly to options.txt.

I'm worried about your comment that "graph settings are reset to max every time you restart the client." Is this a client where you had previously set both values to max (100)? By default, graph_length and graph_memory should be set to 25 and 100. For me, the client always restarts with these values.

The "core.kinematics.AtomTree [ ERROR ]" is just noisy output from a core Rosetta function, and probably isn't related to any misbehavior in Foldit.

[LociOiling]

I've had many crashes with puzzle 1863 on devprev on Windows.

A little odd, since 1863 is a "refinement" puzzle with no filters.

I used "share with scientits" on a solution which crashes using DRemixW on low wiggle power.

The crashes generated debug.txt files. The traceback info in the files was all of the "no symbol" variety.
Not likely to be helpful.

I've switched over to main on a couple of clients, we'll see what happens there.

Other puzzles don't seem as affected.

In particular, 1862 seems to be running fine on devprev.

Do the debug.txt files get uploaded automatically or is that my imagination?

[bkoep]

Yes, the debug.txt file is automatically uploaded whenever you restart a client after a crash.

The debug.txt info is good, but more helpful are instructions for reproducing crashes. I will check out the solution you shared in puzzle 1863, thanks!

[Bletchley Park]

I did not choose my words correctly here, the settings were from values manually chosen in a previous client,
"graph_options/graph_length_value" : "79"
"graph_options/graph_memory_value" : "100"

This is what I referred to as 'max', in comparison to the values I chose in the current client, 25 and 33.

So the issue is that the values from options.txt are read, but not written to when changed in the current devprev client. If I restart the current client, it will adopt the values that I edited in the options.txt file itself.

I'm glad to hear the kinematics error is not critical, thanks for reassuring.

[Formula350]

Bletchley_Park
I suspect you may have pulled your initial Log contents from the wrong file, or you have some deeper issues with
your game that may merit redownloading the cmp-binary! Your log file says:
buildid: 20190408-594bfb6c6c-win_x86-devprev
(the fact it spammed "loading hotkey fileloading hotkey fileloading hotkey file" at the start tipped me off, as that was fixed a few builds back)

If that really is the build from whatever client crashed, then I'd say it's no wonder it crashed :P

Also, your other comment mentions build "20200409-d067627d3b-win_x86". Hopefully that was just for comparison?
As even that is a number of updates OUT of date :S

I only mention that due to the relevancy of the crashes and how many updates we've had, which in turn may have
already addressed those problems.

As for RAM usage… I've noticed that Foldit is using more now with the latest DevPrev (20200707), however, I
personally welcomed it. So long as it is intended! heh It's easy to adjust RAM usage through the settings, but
it's not easy to tell it to use more, when maybe it may help! :)

That being said. This may or may not be helpful given the version updates we've gone through, but prior to the
launch of BUNS, I was having a lot of problems with crashing while hand folding. Susume had mentioned that an
old trick was to lower it to 75%, so I checked… It already was. As such, I figured I'll put it BACK to 100%
and see how that does.

Verdict: LESS crashing for me.
Why? Because now Foldit was doing EVERYTHING in RAM, instead of using Disk as swap. It was those saves to disk
that would cause this micro-pause in the game, juuust enough that while hand folding it would trigger Windows
to report "Not Responding" status, and if I didn't "wait" due to not noticing it was 'stalled', it would in turn
cause a crash!
With it set to 100%, the momentary pausing is no more and I have way fewer crashes.

As far as crashes in general, there's definitely some settings in Foldit that seem to inherently cause a client
to be more crash-prone, and one is Stick or Line views (perhaps Trace as well), particularly with Mutations (though
Susume was able to determine that minimizing Foldit while running a recipe can prevent a specific mutation crash).
The other, unfortunately, seems to he "View Bondable H", or at least a contributing part.

So my advice, even if you generally have all other settings disabled, is to run in Cartoon mode, just to be safe.

[Bruno Kestemont]

High CPU usage in Devprev with puzzle 1862 (binding) and the symmetric one.

With 4 cores i7, I use to be able to run 3 clients. It's now limited to 2 (almost 100%) with a high probability of crash.
Even 1 client might crash after an hour running recipes.

My impression is that recipes using filter on/off has more probability to crash with the symmetric puzzle.

[Bruno Kestemont]

2 crashes after 1 hour running puzzle 1862 on 2 clients on Windows 7.

[LociOiling]

Multiple crashes with 1864 and 1865 on devprev.

A debug.txt is generated each time, but the traceback does not appear to contain useful information.

Similar to the problems I had with 1863, the crashes seem to hit remix in particular.

Switching the client back to main seems to reduce or eliminate the crashes.