Divide by zero error thrown from library function call

[Joe Betz]

General question: how do you go about debugging divide by zero errors that occur in external libraries? Is there any additional information that can be obtained by running the VM in debug mode, or otherwise being able to inspect the VM state via a C++ debugger?

Context: I'm in the process of rewriting and updating https://github.com/amaurel/dolphin-chrome-embedded for Dolphin 7, and am getting a divide by zero exception from CEF's renderer subprocess. The subprocess is started by a Dolphin ToGo distributable that exists only to start the subprocess and nothing more. And I'm at wits end for how to debug it without being able to see the call stack inside the library.

Dolphin's dump report only seems to be telling me that it happens inside a call to cef_execute_process. As far as I can tell the arguments to the external method are correct, because the calls succeed for other subprocesses, just not the renderer.

Also, the library works correctly if I use CEF's example subprocess executable (cefclient.exe) rather than the Dolphin ToGo executable (BrowserSubprocess.exe) I created. I mention that in case there are any caveats or known issues with ToGo executables that could be relevant.

The library is published at https://github.com/JBetz/Dolphin-CEF. Reproducing the issue is currently nontrivial, but I'm aiming to make it as simple as opening an image and running a one liner.



********************* Dolphin Virtual Machine Dump Report **********************


02:54:25, 20/10/2023: Division by zero of 1.0

*----> VM Context <----*
Process: {1AE30210:size 221 words, suspended frame 1AE3042D, priority 5, callbacks 0, FP control 80007, thread 00000000}
Active Method: SessionManager>>logError:
IP: 02360769 (9)
SP: 1AE30684
BP: 1AE30658 (259)
ActiveFrame: {1AE3065C: cf 1AE3063D, sp 1AE30674, bp 1AE30658, ip 5, CefRuntimeSessionManager(SessionManager)>>logError:}
receiver: a CefRuntimeSessionManager
arg[0]: a ZeroDivide

New Method: VMLibrary>>dump:path:stackDepth:walkbackDepth:
Message Selector: dump:path:stackDepth:walkbackDepth:

*----> Stack Back Trace <----*
{1AE3065C: cf 1AE3063D, sp 1AE30674, bp 1AE30658, ip 5, CefRuntimeSessionManager(SessionManager)>>logError:}
receiver: a CefRuntimeSessionManager
arg[0]: a ZeroDivide

{1AE3063C: cf 1AE3061D, sp 1AE30650, bp 1AE30638, ip 15, CefRuntimeSessionManager>>logError:}
receiver: a CefRuntimeSessionManager
arg[0]: a ZeroDivide

{1AE3061C: cf 1AE305FD, sp 1AE30630, bp 1AE30618, ip 3, CefRuntimeSessionManager(SessionManager)>>unhandledException:}
receiver: a CefRuntimeSessionManager
arg[0]: a ZeroDivide

{1AE305FC: cf 1AE305DD, sp 1AE30610, bp 1AE305F8, ip 3, CefRuntimeSessionManager(SessionManager)>>onUnhandledError:}
receiver: a CefRuntimeSessionManager
arg[0]: a ZeroDivide

{1AE305DC: cf 1AE305C1, sp 1AE305F0, bp 1AE305DC, ip 5, ZeroDivide(Error)>>defaultAction}
receiver: a ZeroDivide

{1AE305C0: cf 1AE3058D, sp 1AE305D4, bp 1AE305A8, ip 55, ZeroDivide(Exception)>>_propagateFrom:}
receiver: a ZeroDivide
arg[0]: a ExceptionHandler
stack temp[0]: nil
stack temp[1]: a ExceptionHandler
stack temp[2]: nil
stack temp[3]: a Process('Main' base 1AE30000* in SessionManager>>logError: sp=00000000 ip=4 list=02640010)
stack temp[4]: nil

{1AE3058C: cf 1AE3056D, sp 1AE305A0, bp 1AE30588, ip 6, ZeroDivide(Exception)>>_propagate}
receiver: a ZeroDivide
stack temp[0]: nil

{1AE3056C: cf 1AE30551, sp 1AE30580, bp 1AE3056C, ip 13, ZeroDivide(Exception)>>signal}
receiver: a ZeroDivide

{1AE30550: cf 1AE3052D, sp 1AE30564, bp 1AE30548, ip 8, ZeroDivide(Exception)>>signal:with:}
receiver: a ZeroDivide
arg[0]: nil
arg[1]: 1

{1AE3052C: cf 1AE30509, sp 1AE30540, bp 1AE30524, ip 6, ZeroDivide class(Exception class)>>signal:with:}
receiver: ZeroDivide
arg[0]: nil
arg[1]: 1

{1AE30508: cf 1AE304E9, sp 1AE3051C, bp 1AE30504, ip 5, ZeroDivide class(Exception class)>>signalWith:}
receiver: ZeroDivide
arg[0]: 1

{1AE304E8: cf 1AE304C9, sp 1AE304FC, bp 1AE304E4, ip 3, ZeroDivide class>>dividend:}
receiver: ZeroDivide
arg[0]: 1

{1AE304C8: cf 1AE304A5, sp 1AE304DC, bp 1AE304C0, ip 14, ProcessorScheduler>>fpException:}
receiver: a ProcessorScheduler
arg[0]: a ByteArray
stack temp[0]: a _FPIEEE_RECORD

{1AE304A4: cf 1AE30479, sp 1AE304B8, bp 1AE3049C, ip 16, [] in ProcessorScheduler>>vmi:list:no:with:}
receiver: a ProcessorScheduler

{1AE30478: cf 1AE30459, sp 1AE3048C, bp 1AE30474, ip 18, BlockClosure>>ifCurtailed:}
receiver: [] @ 0 in nil
arg[0]: [] @ 24 in ProcessorScheduler>>vmi:list:no:with:

{1AE30458: cf 1AE3042D, sp 1AE3046C, bp 1AE30448, ip 27, ProcessorScheduler>>vmi:list:no:with:}
receiver: a ProcessorScheduler
arg[0]: 540
arg[1]: nil
arg[2]: 10
arg[3]: a ByteArray

{1AE3042C: cf 1AE30401, sp 1AE30440, bp 1AE3041C, ip 0, CefLibrary>>executeProcess_args:application:windowsSandboxInfo:}
receiver: a CefLibrary
arg[0]: a CefMainArgs
arg[1]: a CefApp
arg[2]: 0
stack temp[0]: -402652491

{1AE30400: cf 1AE303E1, sp 1AE30414, bp 1AE303FC, ip 50, CefSubprocessRunner(CefProcessRunner)>>runMainProcess}
receiver: a CefSubprocessRunner
stack temp[0]: nil

[Joe Betz]

I talked over the issue with my business partner and we concluded that running the subprocess with a Dolphin executable isn't worth the effort, not nearly, so this whole divide by zero error is moot.

The Dolphin executable was just a paper thin shell doing nothing more than calling a CEF function that does all the heavy work. The only thing I really wanted it for was to have better control over process lifespans, and to be able to write that logic in Smalltalk rather than C++. But there shouldn't be anything preventing process management from happening in the top-level Dolphin process, even if the CEF's subprocesses are system processes rather than Dolphin processes.

CEF ships with an example executable (cefclient.exe) that can be used for the same purpose. And since it's open source, any extensions or modifications can be done there. So we're just going to use the C++ implementation until it becomes a problem and perhaps use C# and CefSharp to fix it if necessary.

All of the application level logic can still be handled by Dolphin, so I expect the code we have to write in another language to maybe be 1% of the entire project. Really not a big deal.