Halide is very conservative when it comes to error handling, calling abort() whenever an error occur, regardless of the severity. This behavior ends up killing the debugger, most notably during compile_jit() calls.
While there's no easy way to circumvent the issue without major changes to how Halide responds to (and reports) errors, a workaround would be to fork() the debugger process at the compile_jit() site, have the child process try to call it first, and if successful, call it in the parent process.
This is quite silly, but not that terrible...
More annoyingly is the fact that Windows does not have a proper fork() routine...
Update: apparently, it's possible to compile with WITH_EXCEPTIONS and throw an exception out of a custom CompileTimeErrorReporter, or just catch the existing exception thrown by the default CompileTimeErrorReporter. Still an undesirable solution, as it would force the debugger host to have exceptions enabled.
Halide is very conservative when it comes to error handling, calling
abort()whenever an error occur, regardless of the severity. This behavior ends up killing the debugger, most notably duringcompile_jit()calls.While there's no easy way to circumvent the issue without major changes to how Halide responds to (and reports) errors, a workaround would be to
fork()the debugger process at thecompile_jit()site, have the child process try to call it first, and if successful, call it in the parent process.This is quite silly, but not that terrible... More annoyingly is the fact that Windows does not have a proper
fork()routine...Update: apparently, it's possible to compile with
WITH_EXCEPTIONSand throw an exception out of a customCompileTimeErrorReporter, or just catch the existing exception thrown by the defaultCompileTimeErrorReporter. Still an undesirable solution, as it would force the debugger host to have exceptions enabled.