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@wireshark.org > > http://www.wireshark.org/mailman/listinfo/wireshark-dev > > > _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
