Wireshark-bugs: [Wireshark-bugs] [Bug 2017] VoIP trace crashes Wireshark when specific RTP Playe
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2017
------- Comment #23 from jyoung@xxxxxxx 2008-01-04 05:38 GMT -------
> Were you able to get Wireshark to crash while in Valgrind or did you
> just look at the error output to spot the problem?
While I did get Wireshark to crash when run in valgrind a few times, I never
invoked valgrind with the parameter to launch gdb.
Ultimately it was an interative process of running valgrind, reviewing the
valgrind report and instrumentation messages that guided me on where next to
insert more instrumentation code. I would also directly launch Wireshark
within gdb to get a better handle on program flow from a valgrind alert. But a
Valgrind alert on a particular memory read or write can be very far from where
the real problem is. By inserting some lucky and/or stategic printf() of
suspect variables I was able to make valgrind alert closer and closer to the
source line of the problem. It was work, but I doubt I ever would have found
this bug any other way.
The funny thing is that I believe the slowdown caused by running Wireshark from
valgrind actually aided in this finding this particular problem because the
defective code path appeared to be executed more times when valgrind was active
than not. The slowdown caused by using Valgrind ALWAYS caused the temporary
"Refiltering statistics on" window to be displayed with many more updates.
This week I've been getting more comfortable with using valgrind with
Wireshark. As I mentioned before, valgrind generates some pretty verbose
reports. I'm still trying to detremine what particular valgrind messages I
need to pay attention to and which ones I can safely ignore. But today using
valgrind I found and (hopefully) fixed another small bug in epan/emem.c that I
will be uploading shortly.
I hope to take a fresh look at gtk/voip_calls.c to see if I can figure out if
the absence of the g_free(rtp_listinfo->pt_str) does indeed result in a memory
leak. But I think applying either the "option 1" or "option 2" fix is better
than the current existing behavior. ;-)
--
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.
