Comment # 4
on bug 10233
from Hadriel Kaplan
(In reply to Bill Meier from comment #3)
> Is there anything special going on with LUA ?
It's not actually within the Lua--to-C-code API at the time this happens -
i.e., this is happening strictly within normal C-code execution before Lua is
invoked.
In the scenario this occurs in, Lua registered a heuristic dissector, which
actually registers the C-function 'heur_dissect_lua()', found in
epan/wslua/init_wslua.c. The bug happens when that registered heuristic is
invoked through call_heur_dissector_direct(), but does *not* happen when it's
invoked through dissector_try_heuristic().
The reason is that in dissector_try_heuristic() the pinfo->heur_list_name is
correctly set to the registered heuristic's list_name before the dissector
function is called; whereas in call_heur_dissector_direct() the
pinfo->heur_list_name is not set before-hand and is thus left NULL. The
registered heur_dissect_lua() needs that list_name (among other fields) to find
the appropriate Lua function to invoke. So heur_dissect_lua() has this line to
guard against such an error:
if (!tvb || !pinfo || !pinfo->heur_list_name || !pinfo->current_proto) {
report_failure("internal error in heur_dissect_lua: NULL packet info");
return FALSE;
}
Since pinfo->heur_list_name is NULL, the code calls report_failure(), and
indeed when you run Wireshark you see a dialog box pop up, but it's content is
blank and Wireshark appears to hang at that point and exits, asserting in
wmem_scope.
I'll attach the stack trace to this bug, but basically it shows
report_failure() being called from within heur_dissect_lua(), but also then
libgtk continuing and calling gtk_tree_view_column_cell_set_cell_data(),
followed by wireshark calling packet_list_get_value(), then
packet_list_dissect_and_cache_record(), then epan_dissect_run() and finally
wmem_enter_packet_scope().
You are receiving this mail because:
- You are watching all bug changes.