Hello,
On 7/18/22 10:51 AM, Stefan Thöni wrote:
I'm debugging an "invalid signal-context capability" but I can't pinpoint the bug.
From my understanding an "invalid signal-context capability" happens when the signal handler is destroyed before the signal is processed. I have therefore carefully looked at the lifetime of all signal handlers and their corresponding signals, refactoring code to allow signals to be processed before destroying signal handlers.
Is there another condition that triggers an "invalid signal-context capability" besides destroying the signal handler before any corresponding signal is processed?
Is in your case the cap in _deliver_from_ep already invalid (add cap to the error message or check cap.valid()/cap.local_name()) or looks the cap valid and the context is not found ?
Does anyone have any tips on how to find which signal handler caused an "invalid signal-context capability" or where the signal originated?
When the error case triggers, you may extend the local Rpc_deliver with a error return value, which you may check on the caller side (submit(cap,cnt)). If the error code is set you may print the thread name of the caller and make a Genode::backtrace() to find the source.
Hope it helps,
Alex.