Wireshark-dev: Re: [Wireshark-dev] proposed change for packet-ssl-utils.h
From: Jaap Keuter <jaap.keuter@xxxxxxxxx>
Date: Fri, 25 May 2007 08:35:32 +0200 (CEST)
Hi,

Checked in.

Thanx,
Jaap

On Thu, 24 May 2007, Brian Vandenberg wrote:

>   I ran into a problem trying to debug some of my stuff yesterday that
> depends on the http dissector, and the server I'm working with defaults
> to ssl traffic; whenever I try to debug it, it always gets hung up on
> the lines I mentioned in the email quoted below (within the ssl dissector).
>
>   It seems the culprit is in the use of g_malloc within ssl_data_alloc,
> and free (instead of g_free) in tls_prf.  In addition to changing lines
> 975, 977, 979, 981, and 983, I also changed line 1771 in the same
> manner; on startup it kept breaking on that line as well, but only on
> startup and when applying new settings to the ssl dissector.  Another
> suggestion I had was to remove all the manual g_free's on the StringInfo
> data members, and add a destructor for the StringInfo object ... but
> that's not as big a deal.
>
>   It looks like the reverse problem may be occurring on line 2026 of
> packet-ssl-utils.c.  Whenever I clear the RSA keys list field and hit
> apply, it breaks on line 2026, which calls g_free.  I'm still kinda
> green to development in wireshark so I'm having trouble seeing where the
> problem is.  The ssl dissector starts by freeing the list of hashes
> (line 317 of packet-ssl.c), then uses g_hash_table_new to shove all the
> new strings in a hash table, and I would expect something from glib to
> be using g_free, so my best (inexperienced) guess is that there's a
> conflict here with g_malloc being called by one binary, and g_free by
> another, neither of which shares the same heap.  That, however, is
> beyond my experience and I'm unsure of how to track this down any further.
>
>   I've attached the diff for the fixes I made.
>
> -Brian
>
> Brian Vandenberg wrote:
> >   I just got a plugin I wrote awhile back compiling under 0.99.5 and
> > tried to run it from within VS2005's debugger.  I loaded up a dump file
> > from tcpdump, then went into preferences & setup the SSL dissector.  As
> > soon as I hit apply I received a message saying:
> >
> > -=-=-=-=-=-=-=-=-=-
> > Windows has triggered a breakpoint in wireshark.exe
> >
> > This may be due to a corruption of the heap, and indicates a bug in
> > wireshark.exe or any of the DLLs it has loaded.
> > -=-=-=-=-=-=-=-=-=-
> >
> >   The output window has the following text:
> >
> > -=-=-=-=-=-=-=-=-=-
> > HEAP[wireshark.exe]: Invalid Address specified to RtlFreeHeap( 022B0000,
> > 04239F68 )
> > Windows has triggered a breakpoint...<repeat of previous text>
> > -=-=-=-=-=-=-=-=-=-
> >
> >   That's from setting the SSL key settings.  Similar things happen
> > during the SSL dissection process.  The only difference each time around
> > seems to be the 2nd parameter of RtlFreeHeap, otherwise the message is
> > identical.  It occurs on lines 975, 977, 979, 981, and 983 of
> > packet-ssl-utils.c.
> >
> >   I vaguely remember something like this happening back when I used to
> > debug with VS6, but it wasn't as big a headache.  Usually I could just
> > F5 through it a few times after-which I didn't have to fool with it
> > anymore, but in VS8 it's quite a pain.
> >
> >   Anyone familiar with this and/or know how to resolve it?
> >
> > -Brian
> > _______________________________________________
> > Wireshark-dev mailing list
> > Wireshark-dev@xxxxxxxxxxxxx
> > http://www.wireshark.org/mailman/listinfo/wireshark-dev
> >
>