Wireshark-bugs: [Wireshark-bugs] [Bug 7400] Update Lua from 5.1 to 5.2
Date: Sat, 23 Feb 2013 21:39:29 +0000

changed bug 7400

What Removed Added
CC   hadrielk@yahoo.com

Comment # 12 on bug 7400 from
I looked into this - I usually use Lua 5.1 without problems, so I switched to
5.2 to repro this bug.  It is indeed happening even in MacOSX, and will in
Linux too for that matter.

There are two "problems" that cause this.
Problem-1) The way classes are registered into Wireshark's Lua in wslua.h is
different between Lua 5.1 and 5.2.  I don't just mean the functions being
called are different, which is different simply due to the API changing in Lua
5.2 - I mean Wireshark is not doing the same thing fundamentally.  

When 5.1 is used, Wireshark creates a global table of the class name with the
class methods as its fields, and creates a metatable of the class name with the
class metamethods.  That's all it does.  Two things should be noted about this:
this metatable is not actually set as the metatable of the global methods
table; and if this macro is called twice it doesn't actually replace the global
table. Those details become important due to Problem-2.

When 5.2 is used, Wireshark creates a new table of the class name, without
setting its table fields to the methods.  It then creates a metatable of the
class name with the class metatamethods, and sets the metatable's __index field
to point to a new table of the class methods, and sets the __metatable field to
point to a new table of the class metamethods.  (Why it does that latter step I
have no idea, and is a bad idea)  Then it sets this metatable to be the
metatable of the original newly-created class table, and then sets that class
table into the global.  That means if this macro is called twice, it will end
up replacing the previous global class table, which results in it being garbage
collected eventually.

Fundamentally Wireshark should be doing the same logical things between Lua 5.1
and 5.2, but it's not.  It should not be replacing an existing global table,
should not be setting the metatable for it, and should not be setting the
metatable's __metatable field to point to the metamethods but rather the
methods instead.  That's bug #1.

Problem-2) The Pref and Prefs classes are registered twice into Lua.  That's
because Proto_register() in wslua_proto.c is registering them both, when it
shouldn't be.  That's bug #2.  They're already registered by the
register_wslua.c file created by the make-reg.pl perl script, as they should
be.

In Lua 5.1 nothing bad happened due to this, because registering the second
time didn't do much.  But in Lua 5.2 this second registration means the first
global class table is being replaced, which means it will be garbage collected,
which triggers the __gc metamethod for it, which for 'Pref' hits Pref_gc (not
for 'Prefs' because it had no __gc metamethod).  Had the Lua 5.2 macro either
not replaced the global table, or not set the global table's metatable, or
neither, this wouldn't have caused the panic.


You are receiving this mail because:
  • You are watching all bug changes.