- Joined
- Aug 6, 2011
- Messages
- 405
- Reaction score
- 2
- Points
- 18
We've all experienced them...the dreaded crash to desktop.
Wouldn't it be great if there was a way to get more information for debugging, or to know which plugin called which Orbiter API function which crashed Orbiter?
catch-ctd is a module which aims to do that.
What is it
Currently, catch-ctd hooks all* of the "free-standing" Orbiter API functions.
These are the functions starting with oapi. Currently, class functions (like functions inside Orbiter classes, like CameraMode::GetMode() ) are not hooked.
Then, catch-ctd simply logs the function and the arguments passed to it to ORBITER_ROOT/catch-ctd/catch-ctd.log.
All Orbiter vessels are now hooked, so you get context about where each Orbiter call comes from.
Log files look like this right now:
What it will be
I want to expand catch-ctd to know which modules are calling each function.
That should be fairly straightforward- just intercept the call to create a new vessel, install an empty "forwarding" class that simply forwards all vessel calls to the actual vessel class. Done
This will be harder for orbiter modules using the old deprecated, non-Module class method. (Where DLLs directly implement functions like oapiPreStep, instead of defining a subclass of Module and implementing Module:reStep)
Install
Requires the VS 2013 redistributable here. (If that direct link doesn't work, use this link and select the x86 redistributable)
Download the current version here, and unzip into Orbiter as usual, then enable in Modules list.
Caveats
catch-ctd doesn't actually catch CTDs :lol:
Even if Orbiter was throwing exceptions, catch-ctd could catch them, but the simulation still has to terminate because it's in a weird state.
As catch-ctd has to write to a file for every OAPI call, it is slow. On a simple scene (DG Brighton Beach scenario), I get around 70 FPS with catch-ctd enabled.
I'm trying to come up with a method to speed up logging, but most involve buffering, which might lose the crucial last call before an Orbiter crash.
*I use Detours to hook the functions, so functions that are too small (like the second oapiMeshGroup overload), as most overloads are, do not get hooked.
This shouldn't matter, as the really small functions probably just call the larger overload, so it gets hooked that way.
Question
---------- Post added at 05:58 PM ---------- Previous post was at 03:15 PM ----------
Updated logging.
Now, there is only one file open/close per line of logging. This increases the FPS in that simple scene from 8 to 21 on my computer. Still not great, but better.
Also, now logging parameters have the argument names along with the arguments. If an argument is a struct, it is printed out in nested parenthesies.
For example,
oapiGlobalToEqu takes five arguments. Every argument except glob is a pointer, and gets their memory address printed out.
The second argument, named glob, is a VECTOR3, and gets the internal address and three components printed out.
Wouldn't it be great if there was a way to get more information for debugging, or to know which plugin called which Orbiter API function which crashed Orbiter?
catch-ctd is a module which aims to do that.
What is it
Currently, catch-ctd hooks all* of the "free-standing" Orbiter API functions.
These are the functions starting with oapi. Currently, class functions (like functions inside Orbiter classes, like CameraMode::GetMode() ) are not hooked.
Then, catch-ctd simply logs the function and the arguments passed to it to ORBITER_ROOT/catch-ctd/catch-ctd.log.
All Orbiter vessels are now hooked, so you get context about where each Orbiter call comes from.
Log files look like this right now:
Code:
Attaching hooks...
Original oapiRegisterModule :66CE68E8
Original oapiGetObjectByName :66CE6764
Original oapiGetObjectByIndex :66CE682C
Original oapiGetObjectType :66CE6620
---snipped list of functions hooked---
---snipped functions called during load of scenario---
Inside DeltaGlider::GL-01::clbkPostStep:simt:1.94122, simdt:0.00735763, mjd:51981.6
...
Inside DeltaGlider::GL-02::clbkPostStep:simt:1.94122, simdt:0.00735763, mjd:51981.6
...
Inside DeltaGlider::GL-03::clbkPostStep:simt:1.94122, simdt:0.00735763, mjd:51981.6
...
Inside ShuttleA::SH-02::clbkPostStep:simt:1.94122, simdt:0.00735763, mjd:51981.6
...
Inside ShuttleA::SH-03::clbkPostStep:simt:1.94122, simdt:0.00735763, mjd:51981.6
...
oapiMeshGroupCount:(hMesh:08706C20)...
oapiMeshGroup:(hMesh:08706C20 , idx:0)...
oapiMeshGroup:(hMesh:08706C20 , idx:1)...
oapiMeshGroup:(hMesh:08706C20 , idx:2)...
oapiMeshGroup:(hMesh:08706C20 , idx:3)...
oapiMeshGroup:(hMesh:08706C20 , idx:4)...
oapiMeshGroupCount:(hMesh:0852D718)...
oapiMeshGroup:(hMesh:0852D718 , idx:0)...
Inside DeltaGlider::GL-01::clbkPanelRedrawEvent:id:14, event:1, surf:00000000, context:125BA090
...
Inside DeltaGlider::GL-01::clbkPanelRedrawEvent:id:13, event:1, surf:00000000, context:125BA0E8
oapiGetNavType:(hNav:085C9D10)...
...
---snipped additional function calls----
Detaching hooks...
Hooks detached successfully
What it will be
I want to expand catch-ctd to know which modules are calling each function.
This will be harder for orbiter modules using the old deprecated, non-Module class method. (Where DLLs directly implement functions like oapiPreStep, instead of defining a subclass of Module and implementing Module:reStep)
Install
Requires the VS 2013 redistributable here. (If that direct link doesn't work, use this link and select the x86 redistributable)
Download the current version here, and unzip into Orbiter as usual, then enable in Modules list.
Caveats
catch-ctd doesn't actually catch CTDs :lol:
Even if Orbiter was throwing exceptions, catch-ctd could catch them, but the simulation still has to terminate because it's in a weird state.
As catch-ctd has to write to a file for every OAPI call, it is slow. On a simple scene (DG Brighton Beach scenario), I get around 70 FPS with catch-ctd enabled.
I'm trying to come up with a method to speed up logging, but most involve buffering, which might lose the crucial last call before an Orbiter crash.
*I use Detours to hook the functions, so functions that are too small (like the second oapiMeshGroup overload), as most overloads are, do not get hooked.
This shouldn't matter, as the really small functions probably just call the larger overload, so it gets hooked that way.
Question
- Is there interest in a plugin like this? Is this something the community needs, or is the current CTD-debugging method enough?
- Does anyone have an idea to speed up logging, without possibly losing information when Orbiter crashes?
- How can I hook modules using the deprecated plugin method?
- Any better names for this?
---------- Post added at 05:58 PM ---------- Previous post was at 03:15 PM ----------
Updated logging.
Now, there is only one file open/close per line of logging. This increases the FPS in that simple scene from 8 to 21 on my computer. Still not great, but better.
Also, now logging parameters have the argument names along with the arguments. If an argument is a struct, it is printed out in nested parenthesies.
For example,
Code:
oapiGlobalToEqu:(hObj:08495038 , glob:(data:00AEEBE0, x:1.43041e+011, y:-2.04222e+007, z:4.69909e+010) , lng:084957E0 , lat:084957E8 , rad:00AEEE48)...
The second argument, named glob, is a VECTOR3, and gets the internal address and three components printed out.
Last edited: