[bugzilla-daemon@xxxxxxxxxxxxx]

http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2017





------- Comment #14 from jyoung@xxxxxxx  2007-12-27 02:16 GMT -------
Hello Steve,

Using gdb, with a breakpoint of "b add_to_graph" (from the file voip_calls.c)
I've occasionally been able to cause Wireshark to crash earlier rather than
later.  The backtraces are not 100% consistent, but with the breakpoint enabled
(and with some extra debug printf()s in place), more often than not the crash
shows up before the "VoIP Calls" window is even displayed the first time. 
These earlier crashes are more likely to show up in pango_item_free(). Here's a
 backtrace report that's pretty representative of what I'm currently seeing:

<snip>
Breakpoint 1, add_to_graph (tapinfo=0x817e100, pinfo=0x8fcaa78,
frame_label=0x8f44de0 "facility",
    comment=0x8fdc790 "H225 TunnH245:off FS:on", call_num=0,
src_addr=0x8fcaabc, dst_addr=0x8fcaac8, line_style=1)
    at voip_calls.c:211
211     {
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x41c8466a in pango_item_free () from /opt/gnome/lib/libpango-1.0.so.0
(gdb) bt
#0  0x41c8466a in pango_item_free () from /opt/gnome/lib/libpango-1.0.so.0
#1  0x41c85977 in pango_layout_line_index_to_x () from
/opt/gnome/lib/libpango-1.0.so.0
#2  0x41c859ec in pango_layout_line_unref () from
/opt/gnome/lib/libpango-1.0.so.0
#3  0x41c85a73 in pango_layout_line_unref () from
/opt/gnome/lib/libpango-1.0.so.0
#4  0x41c85fed in pango_layout_set_width () from
/opt/gnome/lib/libpango-1.0.so.0
#5  0x41d00743 in g_object_unref () from /opt/gnome/lib/libgobject-2.0.so.0
#6  0x419ba908 in gtk_label_get () from /opt/gnome/lib/libgtk-x11-2.0.so.0
#7  0x419bc6c0 in gtk_label_set_attributes () from
/opt/gnome/lib/libgtk-x11-2.0.so.0
#8  0x419bd009 in gtk_label_set_text () from /opt/gnome/lib/libgtk-x11-2.0.so.0
#9  0x080f5e41 in voip_calls_dlg_update (list=0x8e6c610) at
voip_calls_dlg.c:192
#10 0x080f60c4 in voip_calls_dlg_draw (ptr=0x817e144) at voip_calls_dlg.c:886
#11 0x4045c4b9 in draw_tap_listeners (draw_all=0) at tap.c:333
#12 0x0808028d in update_cb (data=0x0) at main.c:1404
#13 0x41f91106 in g_main_context_wakeup () from /opt/gnome/lib/libglib-2.0.so.0
#14 0x41f8f35c in g_main_context_dispatch () from
/opt/gnome/lib/libglib-2.0.so.0
#15 0x41f927cb in g_main_context_check () from /opt/gnome/lib/libglib-2.0.so.0
#16 0x41f92ae7 in g_main_loop_run () from /opt/gnome/lib/libglib-2.0.so.0
#17 0x419cc861 in gtk_main () from /opt/gnome/lib/libgtk-x11-2.0.so.0
#18 0x080831d6 in main (argc=0, argv=0xbfa93218) at main.c:3103
(gdb)

I've added some instrumentation code (basically printf()s) to report the
addresses of the various address.data buffers created by the COPY_ADDRESS()
macro and just prior to any g_free()s of same within the voip_calls.c module. 
I also added some printf()s simply to report entering and leaving various
functions in voip_calls_dlg.c.  The presence of the printf()s along with the
gdb breakpoint along with using various subsets of the original problem trace
file make it more likely or less likely to get a consistent crash results.  
Given the various crash results I'm seeing I suspect that memory has been
corrupted long before we actually see the problem.

Seeing the crash detected by a pango function makes sense given the odd text I
would occasionally noticed within the labels of the "Refiltering statistics
on:" and in the "VoIP Calls" windows (see comment #4 and comment #6).  Further
evidence that something has trashed some part of memory.   

I'm guessing that having both the extra printf()s and having the gdb breakpoint
interrupt the normal program flow is causing the runtime memory footpoint of
Wireshark to change just enough to expose the results of the underlying bug
earlier rather than later.  Hopefully with some extra instrumentation we'll be
able to narrow this down even more.

If interested I can upload the subset trace file and a patch file with the
instrumentation code that I'm currently using to help isolate this bug.


-- 
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.