Tracebacks from ignored underflows

[hartytp]

The ndscan ignore underflows feature currently leads to unhelpful tracebacks which just point into ndscan.experiment.entrypoint rather than any user code. AFAICT this is not ndscan's fault, just a manifestation of m-labs/artiq#1836 but I thought it might be worth having an issue here to track upstream since it impacts the utility of the ndscan feature (as it makes debugging underflows much harder IME).

[dnadlinger]

This is definitely an annoying issue; in the past, I've found myself temporarily disabling underflow retrying (by editing the source code) to debug these issues.

There are two components to this, though: Even if exception backtraces worked robustly, we'd still need to be able to access a backtrace for kernel exceptions without actually letting the exception propagate to the host. This will probably require a (small) addition to the kernel-facing runtime API.

[hartytp]

This is definitely an annoying issue; in the past, I've found myself temporarily disabling underflow retrying (by editing the source code) to debug these issues.

Me too. I even thought about making it easy to disable this from the GUI as it's something that can crop up a lot during initial development.

There are two components to this, though: Even if exception backtraces worked robustly, we'd still need to be able to access a backtrace for kernel exceptions without actually letting the exception propagate to the host. This will probably require a (small) addition to the kernel-facing runtime API.

You mean so that we can print a traceback when there is just one underflow (so that the underflow is never re-raised)?

[dnadlinger]

You mean so that we can print a traceback when there is just one underflow (so that the underflow is never re-raised)?

Yes – otherwise, non-deterministic underflows can be really annoying to track down.

As for the case where it does result in an exception, yes, that is then something like m-labs/artiq#1836.