Gridcoin-research: Silent Crash / Runtime error

[Quezacoatl1]

Hello devs :)

I am on 3.5.9.0 on Windows 10. I tested the download blocks feature successfully, but the client silently shut down stating pretty much nothing in the last lines of the debug.log

06/06/17 18:58:02

getblocks stopping at limit 854700 0d8af78ee0aa376fa1d6
06/06/

When startingthe client again, it stops at Loading LevelDB (in the debug.log) with a runtime error (as a prompt). When trying to erase appdata files, some files in the txleveldb are "used by another program" until I reboot the computer.
Is it possible some sub program does not close completely?

Some more of my debug.log: https://pastebin.com/krxA6phP

[iFoggz]

seems like some threads may still be open after the crash and likely weren't called to shutdown properly?. I'm not too familiar on the threading topic. nothing in db.log? event viewer information about crash? We probably should add some kind of global setup to catch all errors/crashes and record them.

[Quezacoatl1]

db.log was empty.

I never worked with event viewer but I can not find any indication of gridcoinresearch.exe there. Will try to reproduce it tomorrow.

[Quezacoatl1]

There is nothing in the event viewer, neither the silent crash nor the runtime error.

A user approached us on Facebook about the same issue.

[Quezacoatl1]

With the Windows Process Explorer I could see that gridcoinresearch.exe is not completely closed when crashed.
When hovering over the process, it tells me

"Path:
A connected device is not working."[translation from German]

Killing the process (it was actually 2 processes) got me running Gridcoin again. This is how the Process explorer looks like after a crash (which might be caused by me running BOINC 100% CPU load...)

[iFoggz]

yea in a crash not all threads are necessarily shutdown. it like a stray. But hard to pin point this one actually. u were downloading blocks yes but at same time other wallets were downloading blocks from u (getblocks)

[Quezacoatl1]

I somehow solved one part, the not completely closing part, maybe it was caused by a USB stick I did not safely remove.

[Quezacoatl1]

I think I could also stabilize the client by putting maxconnections=10 and listen=0 into the .conf

[denravonska]

I think I might have an idea why this is but I'm not sure how to prove it.
Note to self: StakeMiner does not lock the mutex when processing a block.

Edit: That was an unreleased bug, nvm.

[tomasbrod]

That may be it. We have to enter critical section cs_main before calling ProcessBlock.

[denravonska]

Just pushed a fix for it at 0a4d34ff3417f450aa8d52da9079b296b549d9ac.

[denravonska]

My fix was unrelated.

[RoboticMind]

can this be closed?

[denravonska]

Closing until we see this again.