Am 23. Juni 2020 um 21:17 Uhr schrieb "Nicholas Jankowski":
> running John's command, however, does lock the main octave program until you quit from adb, though, so i'm not sure if there's another way to call it that it will catch an exception that crashes octave.
That is the expected behavior when gdb attaches to a process. At that point, you would e.g. be able to add breakpoints if you needed to.
When you are ready continue executing the process with the command "continue" (or just "c") at the gdb prompt.
After that the gdb prompt seems "unresponsive" because execution returned to Octave.
ok, thanks. maybe this is something we could detail over on the wiki? I know there's a spot for collecting hard-to-troubleshoot windows crash issues here:
not sure if there's a better place for this. but for general clueless windows users like me, something including
- the command to start adb
system (sprintf ("start gdb -p %d", getpid ()));
- the way to get back to 'normal' octave operation
'continue'
- then run octave as normal to recreate the crash, and .... what's next? generate a report? it'll automatically generate one? do we need to run commands before 'continue' to tell it what/where to dump some output?
- and what to send back to the help list to help developers troubleshoot?
- if any of this falls under 'fails to start', can this be started from the CLI before launching Octave to capture the startup crash details?