Evan Huus
changed
bug 9932
Comment # 1
on bug 9932
from Evan Huus
Valgrind just gives me the following, which doesn't appear possible on a simple
reading of the code...?
==2660== Invalid read of size 1
==2660== at 0x68307B8: my_dgt_tbcd_unpack (packet-gsm_a_common.c:1965)
==2660== by 0x6833B5A: de_bcd_num (packet-gsm_a_dtap.c:2210)
==2660== by 0x6833CE2: de_cld_party_bcd_num (packet-gsm_a_dtap.c:2331)
==2660== by 0x682F530: elem_lv (packet-gsm_a_common.c:1728)
==2660== by 0x68490A1: rp_data_n_ms (packet-gsm_a_rp.c:282)
==2660== by 0x6849387: dissect_rp (packet-gsm_a_rp.c:512)
==2660== by 0x655E3D3: call_dissector_through_handle (packet.c:595)
==2660== by 0x655ECC4: call_dissector_work (packet.c:682)
==2660== by 0x65607F1: call_dissector_with_data (packet.c:2260)
==2660== by 0x6834696: de_cp_user_data (packet-gsm_a_dtap.c:3330)
==2660== by 0x682F530: elem_lv (packet-gsm_a_common.c:1728)
==2660== by 0x6838C7E: dtap_sms_cp_data (packet-gsm_a_dtap.c:5465)
==2660== Address 0x12f97040 is 0 bytes after a block of size 48 alloc'd
==2660== at 0x4C2A420: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2660== by 0x977B610: g_malloc (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==2660== by 0x701D5AF: wmem_simple_alloc (wmem_allocator_simple.c:50)
==2660== by 0x658CFCA: tvb_memdup (tvbuff.c:781)
==2660== by 0x6833B34: de_bcd_num (packet-gsm_a_dtap.c:2207)
==2660== by 0x6833CE2: de_cld_party_bcd_num (packet-gsm_a_dtap.c:2331)
==2660== by 0x682F530: elem_lv (packet-gsm_a_common.c:1728)
==2660== by 0x68490A1: rp_data_n_ms (packet-gsm_a_rp.c:282)
==2660== by 0x6849387: dissect_rp (packet-gsm_a_rp.c:512)
==2660== by 0x655E3D3: call_dissector_through_handle (packet.c:595)
==2660== by 0x655ECC4: call_dissector_work (packet.c:682)
==2660== by 0x65607F1: call_dissector_with_data (packet.c:2260)
But if I run it through test-captures.sh I get the following stack trace:
#0 call_dissector_work (handle=0x3030303030303030, tvb=0x3646540,
pinfo_arg=0x3611478, tree=0x3030303030303030, add_proto_name=1, data=""
at packet.c:636
#1 0x00007f001c4ccf5a in de_rp_user_data (tvb=0x36464a0, tree=<optimized out>,
pinfo=0x3611478, offset=13, len=4, add_string=<optimized out>,
string_len=1024) at packet-gsm_a_rp.c:164
#2 0x00007f001c4b3531 in elem_lv (tvb=tvb@entry=0x36464a0,
tree=tree@entry=0x40f18f4, pinfo=pinfo@entry=0x3611478,
pdu_type=pdu_type@entry=2,
idx=idx@entry=3, offset=offset@entry=12, len=len@entry=49,
name_add=name_add@entry=0x0) at packet-gsm_a_common.c:1728
#3 0x00007f001c4cd0fa in rp_data_n_ms (tvb=0x36464a0, tree=0x40f18f4,
pinfo=0x3611478, offset=<optimized out>, len=<optimized out>)
at packet-gsm_a_rp.c:284
#4 0x00007f001c4cd388 in dissect_rp (tvb=0x36464a0, pinfo=0x3611478,
tree=<optimized out>) at packet-gsm_a_rp.c:512
#5 0x00007f001c1e23d4 in call_dissector_through_handle
(handle=handle@entry=0x24f1bc4, tvb=tvb@entry=0x36464a0,
pinfo=pinfo@entry=0x3611478,
tree=tree@entry=0x358b330, data="" at packet.c:595
Based on the values of handle and tree, something is smashing the space of
globals...?
You are receiving this mail because:
- You are watching all bug changes.