DEBUG: lua: precisely identify if stream is stuck inside lua or not
When ha_panic() is called by the watchdog, we try to guess from
ha_task_dump() and ha_thread_dump_one() if the thread was stuck while
executing lua from the stream context. However we consider this is the
case by simply checking if the stream hlua context was set, but this is
not very precise because if the hlua context is set, then it simply means
that at least one lua instruction was executed at the stream level, not
that the stuck was currently executing lua when the panic occured.
This is especially true with filters, one could simply register a lua
filter that does nothing but this will still end up initializing the
stream hlua context for each stream. If the thread end up being stuck
during the stream handling, then debug dumping functions will report
that the stream was stuck while handling lua, which is not necessarilly
true, and could in fact confuse us even more.
So here we take another approach, we add the BUSY flag to hlua context:
this flag is set by hlua_ctx_resume() around lua_resume() call, this way
we can precisely tell if the thread was handling lua when it was
interrupted, and we rely on this flag in debug functions to check if the
thread was effectively stuck inside lua or not while processing the stream
No backport needed unless a commit depends on it.
(cherry picked from commit 1a2cdf64c9e33495b993771da8759aac9d3dd0ba)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit c821ed963b1583225ed6979ebb0b2ed4987b3e79)
[cf: No need to fix ha_thread_dump_one()]
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 4796ace0fadc7282a40eb2417faf7f9af85bde57)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 46f39164888ad106f735945f3468e3acb677cef5)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 646be69d5b940ac8a637355cc42d2c864609527d)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
4 files changed