Crash when newly added display filter macro is first used
This issue was migrated from bug 2068 in our old bug tracker.
Original bug information:
Reporter: Jim Young
Status: RESOLVED FIXED
Product: Wireshark
Component: GTK+ UI
OS: All
Platform: x86
Version: Git
Attachments:
bug2068.patch: fix to macro_copy() function of epan/dfilter/dfilter-macro.c.
Activity
Build Information: Version 0.99.7pre2 (SVN Rev 23672)
Copyright 1998-2007 Gerald Combs <gerald@wireshark.org> and contributors. 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 with GTK+ 2.12.1, with GLib 2.14.3, with WinPcap (version unknown), with libz 1.2.3, with libpcre 6.4, with SMI 0.4.5, with ADNS, with Lua 5.1, with GnuTLS 1.6.1, with Gcrypt 1.2.3, with MIT Kerberos, with PortAudio PortAudio V19-devel, with AirPcap.
Running on Windows XP Service Pack 1, build 2600, with WinPcap version 4.0.2 (packet.dll version 4.0.0.1040), based on libpcap version 0.9.5, without AirPcap.
Built using Microsoft Visual C++ 6.0 build 8804
Wireshark is Open Source Software released under the GNU General Public License.
Check the man page and http://www.wireshark.org for more information.
Hello this bug concerns the use of the "Display Filter Macros". After a new display filter macro (dfmacro) has been defined, the first attempt to use the dfmacro will result in a crash of Wireshark when the closing "}" character is entered into the "Filter:" text entry field. This bug has been replicated on severalof Microsoft Windows based versions of Wireshark including: Version 0.99.7pre2 (SVN Rev 23672). Version 0.99.6a (SVN Rev 22276) (last public release) Version 0.99.8-SVN-23698 (SVN Rev 23698) (very recent buildbot version) The bug has also been replicated on a SUSE (linux) system running a very recent SVN (23698): How to replicate this bug: 1: Open the "Display Filter Macros" dialog. Starting with SVN 23693 this item is found in the menu item "Analyze" -> "Display Filter Macros...". Prior to SVN 23693 this item is found "View" -> "Display Filter Macros...". 2: Click on the "New" button to open the "Display Macros Filters: New" dialog. 3: Enter a unique name for the new dfmacro's name: e.g. "foo2" 4: Enter a valid display filter in the text field: e.g. "bootp.dhcp" 5: Click "Ok" to accept and close the "Display Macros Filters: New" dialog. This will redisplay the "Display Filter Macros" dialog. The new dfmacro should be the bottom-most entry in the list. 6: Click in the "Ok" to close the "Display Filter Macros" dialog box. 7: Click in Wireshark's "Filter:" text entry field. 8: Start entering the newly created dfmacro in the "Filter:" text entry field. Please note that the syntax for using a dfmacro requires that you enter the dfmacro's name as ${MACRONAME}. So assuming that you entered the dmacro name as "foo2" you would enter "${foo2}" 9: Wireshark will crash when you enter the closing "}" for the newly created dfmacro. On MS Windows systems[1], following the crash, the newly defined dfmacro will be available when Wireshark is restarted. The new dfmacro entry will have been saved to the "dfilter_macros" file when you press "Ok" or "Apply" to close the "Display Filter Macros" file. After restarting Wireshark you will be able to successfully use the new dfmacro. [1] Unfortunately there is apparently another bug on Linux systems with how the display filter macros entries are saved and restored from the "dfilter_macros" file. On my SUSE (linux) system the dfilter_macros file is updated with the new dfmacro, but upon restart NONE of the dfmacros are loaded. A separate bug will be submitted regarding problems with reading entries from the dfilter_macros file on Linux systems. This bug only happens for newly created dfmacros, Wireshark does NOT crash when attempting to use existing dfmacro names. When I reproduce this bug on my SUSE system I get a consistent back-trace pointing to "g_string_sprintfa(text,"%s%s"," located in epan/dfilter/dfilter-macro.c:195... > ~/projects/wireshark> ulimit -c unlimited > ~/projects/wireshark> ./wireshark & <reproduce the crash> > ~/projects/wireshark> libtool --mode=execute gdb wireshark core <snip> > #0 dfilter_macro_resolve (name=0x942b690 "foo2", args=0x942b6d8, error=0x8176d00) at dfilter-macro.c:195 195 g_string_sprintfa(text,"%s%s", (gdb) where > #0 dfilter_macro_resolve (name=0x942b690 "foo2", args=0x942b6d8, error=0x8176d00) at dfilter-macro.c:195 > #1 0x40478b02 in dfilter_macro_apply (text=0x89dbbc0 "${foo2}", depth=0, error=0x8176d00) at dfilter-macro.c:289 > #2 0x40477b2d in dfilter_compile (text=0x89dbbc0 "${foo2}", dfp=0xbffbbd9c) at dfilter.c:225 <snip>added crash uigtk versiondev labels
-
Created attachment 1307 fix to macro_copy() function of epan/dfilter/dfilter-macro.c. Attached is a patch for bug 2068. There were several problems found in the macro_copy() function of epan/dfilter/dfilter-macro.c. #1: The size of the d->parts array cloned from m->parts was one pointer too short (missing the final NULL pointer). #2: The d-parts array cloned from m->parts was referencing pointers into the original m->priv and not into the new d-priv. #3: The d->priv string cloned from m->priv did not include all the string sections from the original m->priv. The patch includes a new DEBUG_MACRO which can be used to dump to stdout the contents of the various dfilter_macro_t structs at various execution points. This DEBUG_MACRO functionality can be enabled be uncommenting the /* #define DUMP_DFILTER_MACRO */ line near the top of the patched dfilter-macro.c file.