[bugzilla-daemon@xxxxxxxxxxxxx]

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





------- Comment #6 from jyoung@xxxxxxx  2007-12-02 09:28 GMT -------
OK, fewer steps needed to reproduce this bug:

  1: Open the "problem" voip trace file.
  2: Click on "Statistics -> VoIP Calls" menu item to open the "VoIP Calls"
window.
  3: In the "VoIP Calls" window click on the "Close" button.  This should
return focus back to the main Wireshark window.

Repeat steps 2 through 3 until Wireshark crashes.   

What is odd about the trace file that triggers this bug is that it contains
three (3) VoIP Calls and NOT the just one as "Detected" by the "VoIP Calls"
window.  

The first seven RTP flows starting at time 0 is the first call for an elapsed
duration of 78 seconds (frames 1-7769).

The next two RTP flows starting at about 161 seconds is the second call an
elapsed duration of about 53 seconds (frames 7778-13184).

The last four RTP flows starting at about 233 seconds is the third call for an
elapsed duration of 35 seconds (frames 13185-16809).

I'm wondering if there are assumptions made in the algorithm that helps
delineate one "VoIP Call" from another that does not hold true for this problem
trace which ultimately leads to something like an extra g_free().

Similar to what Steve reported in Comment #5, I also saw in gdb that most of
the stack traces indicated that the crash was in malloc_consolidate().  But
also like Steve I got a few stack traces that reported the same
voip_calls_on_destroy() -> voip_call_dlg_reset() -> voip_calls_reset() with the
call to g_free((void
*)graph_item->src_addr.data).  Unlike Steve I did NOT set the MALLOC_CHECK
environment variable.

>From the problem trace file I generated six new trace files.   First I
generated three "single call" traces (call1, call2 and call3) each containing
just the range of frames cited above.  I could NOT replicate the problem with
any of the "single call" traces.

I then used mergecap to build three "two call" trace files: call1+call2 (13176
frames in total), call1+call3 (11394 frames in total), and call2+call3 (9032
frames in total).  

I had to repeat steps 2 and 3 quite a few times than I did with the original
(complete) trace file, but I eventually managed to get the call1+call2 trace
and the call1+call3 trace to crash.  I couldn't get the call2+call3 trace to
crash.   

Although "call #1" is a common denominator in all my crashes I'm wondering if
the total length of the trace file (in frames) has some bearing on the problem. 

There is one oddity in "call #1"; it has one very short duration RTP flow (0.12
seconds, from 10.0.1.45:2128 to 10.1.17.20:2674) of 6 frames in total.  This
flow can be found with the filter "ip.src==10.0.1.45 && udp.srcport==2128". In
the actual RTP graph in the RTP Player window this particular flow doesn't
indicate where it starts (+6.2 seconds) in relationship to the beginning of the
trace file.  All the other RTP flow graphs have a "seconds ruler" below their
graphs.  The lack of the "seconds ruler" for this particular RTP flow is
probably just an artifact of being a very short RTP sequence (less than one
second) and all the frames (6 in total) having been captured within the same
one second interval.

Here are a few more observations regarding trying to reproduce the crash:

Similar to what I reported about the "Status:" label in Comment #4, I've also
seen a few occasions where the "From" column on the "VoIP Calls" window
contains random unicode characters.  In this case its NOT the column label
"From" that is corrupted, but the first cell just below it.   When the "VoIP
Calls" window is first displayed this particular cell initially contains the
text "Please wait..." .  For the problem trace the "From" and "To" columns are
always blank.  Apparently the source and destination caller numbers could not
be extracted from the the control plane frames.

I've noticed that I do not consistently see the temporary "Refiltering
statistics on" window with the smaller trace files.   If the temporary
"Refiltering statistics on" window is displayed, then when it is destroyed, the
"VoIP Calls" window will move behind the main Wireshark window.   If I don't
see the temporary "Refiltering statistics on" window then the "VoIP Calls"
window once displayed will stay on top.  (I suspect that this is simply an
internal GTK windows refresh thing and not really related to the current bug.)

I've been UNSUCCESSFUL in reproducing this crash with other sample "VoIP" trace
files including the "h223-over-rtp.pcap" from the Capture Sample pages of the
wiki. :-(


-- 
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.