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
Index: packet-ssl-utils.c
===================================================================
--- packet-ssl-utils.c (revision 21891)
+++ packet-ssl-utils.c (working copy)
@@ -972,15 +972,15 @@
ssl_print_string("PRF out",out);
free_all:
- free(s2.data);
+ g_free(s2.data);
free_s1:
- free(s1.data);
+ g_free(s1.data);
free_seed:
- free(seed.data);
+ g_free(seed.data);
free_md5:
- free(md5_out.data);
+ g_free(md5_out.data);
free_sha:
- free(sha_out.data);
+ g_free(sha_out.data);
return r;
}
@@ -1768,7 +1768,7 @@
ssl_debug_printf("ssl_load_key: can't import pem data\n");
return NULL;
}
- free(key.data);
+ g_free(key.data);
/* RSA get parameter */
if (gnutls_x509_privkey_export_rsa_raw(priv_key, &m, &e, &d, &p, &q, &u) != 0) {
