In order to isolate/understand the cause of an issue, in certain conditions I would like to halt the debug session in Ozone, in addition I would like periodically to write in a file (or stream?) what `Export.CodeProfile` is showing me at one moment.
By comparing the code profiles, it would be easy to spot the set of functions which suddenly behaves differently.
Is there a way to periodically call `Export.CodeProfile`in Ozone scripting?
I tried to look for similar event catchers like `Break.OnChange` but I couldn't find something which instead of break, would call a function which I override or implement. Moreover, I would like to call it periodically, such as every 10 seconds.
Triggering the breakpoint I have to do from outside of Ozone. In my case I will capture the network and once I detect the conditions where I have to break the execution, I can solve by an UART connection. The external trigger source will send a command to UART and in Ozone I will set a breakpoint where that command is handled. Of course, it would be easier to just have a possibility to tell Ozone using external script or console app, to just break. I can still live with the custom solution with break. It is enough for me to stop nearby the moment of the issue, then after I inspected/understood the situation, I will refine the bug-hunting process.
By comparing the code profiles, it would be easy to spot the set of functions which suddenly behaves differently.
Is there a way to periodically call `Export.CodeProfile`in Ozone scripting?
I tried to look for similar event catchers like `Break.OnChange` but I couldn't find something which instead of break, would call a function which I override or implement. Moreover, I would like to call it periodically, such as every 10 seconds.
Triggering the breakpoint I have to do from outside of Ozone. In my case I will capture the network and once I detect the conditions where I have to break the execution, I can solve by an UART connection. The external trigger source will send a command to UART and in Ozone I will set a breakpoint where that command is handled. Of course, it would be easier to just have a possibility to tell Ozone using external script or console app, to just break. I can still live with the custom solution with break. It is enough for me to stop nearby the moment of the issue, then after I inspected/understood the situation, I will refine the bug-hunting process.