dolphinsmalltalk / Dolphin

Dolphin Smalltalk Core Image
MIT License
301 stars 58 forks source link

Unhandled Win32 Exception 80000003 #1153

Closed jgfoster closed 2 years ago

jgfoster commented 2 years ago

** Dolphin Crash Dump Report ***

Using Dolphin f6c4b3895fcc16fd7f58f65a3463c31fe1be35d3 to build a runtime and I get a crash about every hour or two of active use of the runtime. I believe it happens when presenting or dismissing a dialog. Any advice on what to investigate?

8:34:33 AM, 11/23/2021: Jade.exe caused an unhandled Win32 Exception 80000003 at 0049B6D6 in module 00400000 (C:\Program Files (x86)\Jade\Jade.exe)

----> Exception Parameters <---- 00000000

----> CPU Context for thread 0x2200 <---- EAX = 00002200 EBX = 24833DC0 ECX = 2564BF90 ESI = 1F09FE78 EDI = 1F09FEAC EIP = 0049B6D6 ESP = 1F09FE78 EBP = 1F09FEAC EFL = 00000206 CS = 0023 SS = 002B DS = 002B ES = 002B FS = 0053 GS = 002B

----> Memory Statistics <---- Virtual memory used: 689Mb Virtual memory available: 3405Mb

N.B. This exception did NOT occur in the main Dolphin execution thread

----> CPU Context for main thread 0x1680 <---- EAX = 029D2B70 EBX = 1EF504AC ECX = 1EF502A0 ESI = 0019F530 EDI = 00B57418 EIP = 0049E970 ESP = 0019F4F8 EBP = 0019F508 EFL = 00200246 CS = 0023 SS = 002B DS = 002B ES = 002B FS = 0053 GS = 002B

In module 00400000 (C:\Program Files (x86)\Jade\Jade.exe)

End of crash report

blairmcg commented 2 years ago

That's not a crash as such, 0x80000003 is a hard-coded breakpoint, i.e. like a self halt. There are some of these in the debug VM code as hard assertions of things that are assumed to be a problem, or in one or two cases are heuristics rather than hard conditions. These appear as DebugBreak() calls, or the HARDASSERT macro, or int 3 in the assembler code. They might indicate a problem, and they might not.

Are you running a debug build of the VM? There is really little value in working with a debug build most of the time unless you are actually working on the VM code, or are doing a lot of FFI work when it can sometimes help catch memory corruption from writing off the end of buffers a bit sooner. Otherwise I really wouldn't recommend it. I don't use it when I'm working in Smalltalk.

If you are not running a debug VM, then you might still be hitting a debug check from the heap, which will int 3 if it's metadata gets corrupted, e.g. by a buffer overrun as mentioned, or perhaps by writing to free'd memory. It tends to print some debug trace messages when that occurs, which you will see when running under the debugger. So to investigate further, either start your app under the VS debugger (e.g. just change the debug options for the launcher or VM projects in the solution to open jade.exe, and then F5), or Attach to Process from VS when jade.exe is running. You should find that the debug symbols built for the to-go VM .exe will work, even with your deployed app.

jgfoster commented 2 years ago

It seems that I was somehow running a debug version of the VM (not sure how that happened). I wonder if that is why the executable seems sluggish!

blairmcg commented 2 years ago

Well that is certainly one of the reasons I don't run it routinely :-)