1207 repeatable crash info
| Case number: | 954892-2002216 |
| Topic: | Developer Preview |
| Opened by: | bertro |
| Status: | Open |
| Type: | Bug |
| Opened on: | Wednesday, March 23, 2016 - 19:33 |
| Last modified: | Saturday, March 26, 2016 - 15:10 |
Note: Similar to Susume I believe.
Using puzzle 1207: Quicksaved Soloist Solution 57 Uploaded For Scientists
with minimalist recipe attached.
Will crash in a variable number of iterations.
Files Attached:
- log-crash7.txt
- recipe.lua.txt
- Foldit - crash7.txt (windbg data)
- Foldit.exe.71728.dmp.txt (a CrashDump from a previous crash of the same solution/recipe)
| Attachment | Size |
|---|---|
| log-crash7.txt | 65.17 KB |
| Recipe.lua_.txt | 172 bytes |
| Foldit - crash7.txt | 7.83 KB |
| Foldit.exe_.71728.dmp_.txt | 9.88 MB |
yes win10 completely updated.
I wonder what differences we have that cause this behavior. It did crash a lot of times (always minimized, never had a crash while maximized). Also I ran it standalone and also with windbg attached (after starting client). Crashed both ways.
Interesting. Has anyone had it crash while the client wasn't minimized? (open question)
Well it crashed in the 478th iteration maximized, so not related to that.
I ran my test script on 1207 in a non-minimized window for 4 hours without crashing. All my prior crashes (with minimized window) took an hour or less. I then minimized the window that had been running for 4 hours, and it crashed after 6 minutes. It may be possible to crash a non-minimized client, but I think minimization (or closing the GUI thread) makes it much more likely.
I notice that the tools that are running when the program crashes are tools that generate a thread. Maybe closing that thread (maybe using a corrupted pointer or offset) is what triggers the crash.
Question - when the game client gets an IRC error, does it close a thread?
Here is a copy of windbg output I got after a crash. The error I see is:
FAILURE_ID_HASH_STRING: um:actionable_heap_corruption_heap_failure_block_not_busy_80000003_game_library.dll!library_main
and:
PRIMARY_PROBLEM_CLASS: ACTIONABLE_HEAP_CORRUPTION_heap_failure_block_not_busy_DOUBLE_FREE_game_library!library_main+2ca3762
BUCKET_ID_OFFSET: 2ca3762
BUCKET_ID_MODULE_STR: game_library
BUCKET_ID_MODTIMEDATESTAMP: 56f0b5c3
BUCKET_ID_MODCHECKSUM: 0
BUCKET_ID_MODVER_STR: 0.0.0.0
BUCKET_ID_PREFIX_STR: ACTIONABLE_HEAP_CORRUPTION_heap_failure_block_not_busy_DOUBLE_FREE_
FAILURE_PROBLEM_CLASS: ACTIONABLE_HEAP_CORRUPTION_heap_failure_block_not_busy
FAILURE_EXCEPTION_CODE: 80000003
FAILURE_IMAGE_NAME: game_library.dll
FAILURE_FUNCTION_NAME: library_main
BUCKET_ID_FUNCTION_STR: library_main
FAILURE_SYMBOL_NAME: game_library.dll!library_main
Not having the symbol info for this dll, it is difficult to go further but you should be able...
That was generated after I enabled pageheap (full traces) with gflags.exe
New crash. Only 24 iterations this time. No windbg attached, only crashdump report opened with windbg.
Call stack shows this (I believe) recursive function 'game_library!library_main+0x02a569ca' calling itself 182 times before finally returning.
Hmmm...
I ran this script for 14,000+ iterations with no crash. Are you on Windows?