Bug ID |
10888
|
Summary |
Lua can free tvbuffs too early
|
Product |
Wireshark
|
Version |
1.99.x (Experimental)
|
Hardware |
x86
|
OS |
All
|
Status |
UNCONFIRMED
|
Severity |
Normal
|
Priority |
Low
|
Component |
Dissection engine (libwireshark)
|
Assignee |
[email protected]
|
Reporter |
[email protected]
|
Build Information:
TShark (Wireshark) 1.99.2 (v1.99.2rc0-851-gb714da2 from master)
Copyright 1998-2015 Gerald Combs <[email protected]> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with libpcap, without POSIX capabilities, with libz 1.2.8,
with GLib 2.36.0, with SMI 0.4.8, with c-ares 1.10.0, with Lua 5.2, with GnuTLS
3.1.22, with Gcrypt 1.5.3, with MIT Kerberos, with GeoIP.
Running on Mac OS X 10.9.5, build 13F34 (Darwin 13.4.0), with locale
en_US.UTF-8, with libpcap version 1.6.2, with libz 1.2.8, with GnuTLS 2.12.19,
with Gcrypt 1.5.0.
Intel(R) Core(TM) i7-4960HQ CPU @ 2.60GHz (with SSE4.2)
Built using clang 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56).
--
The current wslua implementation free's up Lua-created tvbuffs right after the
frame is dissected, by registering a frame_end_routine that clears outstanding
tvbuffs. This means the tvbuffs are free'd before cf_callback_invoke() is
called in cf_select_packet() in file.c, which means if the user selects a
packet from the window GUI, then main_cf_cb_packet_selected() will be invoked,
then calling add_byte_views(), which calls get_data_source_name() or
add_byte_tab() and then fails because the tvb is gone.
This will only occur if both the frame has been dissected and Lua has garbage
collected the tvb, and only if the tvb was created by Lua (i.e., through
ByteArray:tvb()). I happen to have a script where that occurs regularly.
Instead, Lua-created tvbuffs should stick around for the life of pinfo. Perhaps
this could be tied into wmem's pinfo pool scope somehow (*not* packet scope).
You are receiving this mail because:
- You are watching all bug changes.