Wireshark-bugs: [Wireshark-bugs] [Bug 10885] Crash when use Telephony / Voip calls
Date: Wed, 11 Mar 2015 02:31:22 +0000
Jeff Morriss changed bug 10885
| What | Removed | Added |
|---|---|---|
| CC | jeff.morriss.ws@gmail.com |
Comment # 3
on bug 10885
from Jeff Morriss
Valgrind says this (amongst other complaints):
~~~
==9624== Conditional jump or move depends on uninitialised value(s)
==9624== at 0x4E799C: packet_list_get_value (packet_list_store.c:377)
==9624== by 0x39AC835574: gtk_tree_model_get_valist (in
/usr/lib64/libgtk-x11-2.0.so.0.2400.25)
==9624== by 0x39AC8358A8: gtk_tree_model_get (in
/usr/lib64/libgtk-x11-2.0.so.0.2400.25)
==9624== by 0x453FCB: packet_list_get_record (packet_list.c:791)
==9624== by 0x456664: packet_list_get_row_data (packet_list.c:1235)
==9624== by 0x523A07: insert_to_graph_t38 (voip_calls.c:433)
==9624== by 0x523A07: t38_packet (voip_calls.c:976)
==9624== by 0x65294FE: tap_push_tapped_queue (tap.c:331)
==9624== by 0x64F9FCB: epan_dissect_run_with_taps (epan.c:344)
==9624== by 0x42A8AE: retap_packet (file.c:2338)
==9624== by 0x42E23D: process_specified_records.constprop.14 (file.c:2308)
==9624== by 0x42E3E2: cf_retap_packets (file.c:2382)
==9624== by 0x4AD895: voip_calls_dlg_init_taps (voip_calls_dlg.c:919)
==9624==
21:43:19 Crit packet_list_get_value: assertion 'iter->stamp ==
packet_list->stamp' failed
(lt-wireshark-gtk:9624): GLib-GObject-WARNING **: gtype.c:4221: type id '0' is
invalid
(lt-wireshark-gtk:9624): GLib-GObject-WARNING **: can't peek value table for
type '<invalid>' which is not currently referenced
==9624== Invalid read of size 8
==9624== at 0x39AC835582: gtk_tree_model_get_valist (in
/usr/lib64/libgtk-x11-2.0.so.0.2400.25)
==9624== by 0x39AC8358A8: gtk_tree_model_get (in
/usr/lib64/libgtk-x11-2.0.so.0.2400.25)
==9624== by 0x453FCB: packet_list_get_record (packet_list.c:791)
==9624== by 0x456664: packet_list_get_row_data (packet_list.c:1235)
==9624== by 0x523A07: insert_to_graph_t38 (voip_calls.c:433)
==9624== by 0x523A07: t38_packet (voip_calls.c:976)
==9624== by 0x65294FE: tap_push_tapped_queue (tap.c:331)
==9624== by 0x64F9FCB: epan_dissect_run_with_taps (epan.c:344)
==9624== by 0x42A8AE: retap_packet (file.c:2338)
==9624== by 0x42E23D: process_specified_records.constprop.14 (file.c:2308)
==9624== by 0x42E3E2: cf_retap_packets (file.c:2382)
==9624== by 0x4AD895: voip_calls_dlg_init_taps (voip_calls_dlg.c:919)
==9624== by 0x39A1E0FD34: g_closure_invoke (in
/usr/lib64/libgobject-2.0.so.0.4200.1)
==9624== Address 0x30 is not stack'd, malloc'd or (recently) free'd
==9624==
==9624==
==9624== Process terminating with default action of signal 11 (SIGSEGV)
==9624== Access not within mapped region at address 0x30
==9624== at 0x39AC835582: gtk_tree_model_get_valist (in
/usr/lib64/libgtk-x11-2.0.so.0.2400.25)
==9624== by 0x39AC8358A8: gtk_tree_model_get (in
/usr/lib64/libgtk-x11-2.0.so.0.2400.25)
==9624== by 0x453FCB: packet_list_get_record (packet_list.c:791)
==9624== by 0x456664: packet_list_get_row_data (packet_list.c:1235)
==9624== by 0x523A07: insert_to_graph_t38 (voip_calls.c:433)
==9624== by 0x523A07: t38_packet (voip_calls.c:976)
==9624== by 0x65294FE: tap_push_tapped_queue (tap.c:331)
==9624== by 0x64F9FCB: epan_dissect_run_with_taps (epan.c:344)
==9624== by 0x42A8AE: retap_packet (file.c:2338)
==9624== by 0x42E23D: process_specified_records.constprop.14 (file.c:2308)
==9624== by 0x42E3E2: cf_retap_packets (file.c:2382)
==9624== by 0x4AD895: voip_calls_dlg_init_taps (voip_calls_dlg.c:919)
==9624== by 0x39A1E0FD34: g_closure_invoke (in
/usr/lib64/libgobject-2.0.so.0.4200.1)
~~~
The basic problem is that the T.38 dissector is passing a frame-number of 0 to
its tap (in t38_info->frame_num_first_t4_data) which then causes heartburn in
packet_list_get_row_data() and below.
An assertion is probably appropriate here:
~~~
--- a/ui/gtk/packet_list.c
+++ b/ui/gtk/packet_list.c
@@ -1228,6 +1228,7 @@ packet_list_get_row_data(gint row)
GtkTreeIter iter;
frame_data *fdata;
+ g_assert(row > 0);
gtk_tree_path_append_index(path, row-1);
gtk_tree_model_get_iter(GTK_TREE_MODEL(packetlist), &iter, path);
~~~
Except for that minor detail that the row number could come from a dissector
(in this case via a tap). Hmmm. Too bad we can except out of taps.
This avoids the crash:
~~~
--- a/ui/voip_calls.c
+++ b/ui/voip_calls.c
@@ -973,6 +973,7 @@ t38_packet(void *tap_offset_ptr, packet_info *pinfo,
epan_dissect_t *edt, const
frame_label = g_strdup_printf("t4-non-ecm-data:%s", tmp_str1);
comment = g_strdup_printf("t38:t4-non-ecm-data:%s
Duration: %.2fs %s",
tmp_str1, duration, t38_info->desc_comment );
+ if (t38_info->frame_num_first_t4_data > 0)
insert_to_graph_t38(tapinfo, pinfo, edt, frame_label, comment,
(guint16)conv_num, &(pinfo->src), &(pinfo->dst),
line_style, t38_info->frame_num_first_t4_data);
~~~
But obviously doesn't solve the root cause. I looked around the T.38 dissector
a bit and it's at least possible the root cause is that evil nasty global
variable p_t38_conv_info. Or maybe it's just a bug but following the logic
seemed a bit much for this evening...
You are receiving this mail because:
- You are watching all bug changes.
- Prev by Date: [Wireshark-bugs] [Bug 10889] Qt Wireshark - On startup occasionally see: Error from waitpid(): Interrupted system call
- Next by Date: [Wireshark-bugs] [Bug 10885] Crash when use Telephony / Voip calls
- Previous by thread: [Wireshark-bugs] [Bug 10889] Qt Wireshark - On startup occasionally see: Error from waitpid(): Interrupted system call
- Next by thread: [Wireshark-bugs] [Bug 10885] Crash when use Telephony / Voip calls
- Index(es):