Wireshark-bugs: [Wireshark-bugs] [Bug 9532] New: Generating a dissector for a sequence of ints g
Date: Mon, 09 Dec 2013 15:43:25 +0000
Bug ID | 9532 |
---|---|
Summary | Generating a dissector for a sequence of ints goes wrong |
Classification | Unclassified |
Product | Wireshark |
Version | 1.10.3 |
Hardware | x86 |
OS | Windows 7 |
Status | UNCONFIRMED |
Severity | Major |
Priority | Low |
Component | Extras |
Assignee | bugzilla-admin@wireshark.org |
Reporter | Andy.Ling@quantel.com |
Created attachment 12276 [details] packet-quentin.c output from omniorb Build Information: wireshark 1.10.3 (SVN Rev Unknown from unknown) Copyright 1998-2013 Gerald Combs <gerald@wireshark.org> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled (32-bit) with GTK+ 2.24.14, with Cairo 1.10.2, with Pango 1.30.1, with GLib 2.34.1, with WinPcap (4_1_3), with libz 1.2.5, without POSIX capabilities, without libnl, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.1, without Python, with GnuTLS 2.12.18, with Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Nov 26 2013), with AirPcap. Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version 4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b (20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap. Intel(R) Core(TM)2 Quad CPU Q6700 @ 2.66GHz, with 8061MB of physical memory. Built using Microsoft Visual C++ 9.0 build 30729 -- I am trying to build a giop dissector from our own CORBA IDL. I am generating the C code using omniorb and the wireshark backend generator using the command.. c:\Python27\omniorb\omniORB-4.1.6\bin\x86_win32\omniidl -p c:\wireshark-1.10.3\tools -b wireshark_be q_quentin.idl > packet-quentin.c I have a function declared in the IDL that looks like.. typedef sequence <long> Longs ; void newThumbnail (in long ident, in long offset, in long width, in long height, in Longs data) ; The packet-quentin.c file contains code that looks like case Request: proto_tree_add_int(tree, hf_Quentin_ThumbnailListener_newThumbnail_ident, tvb, *offset-4, 4, get_CDR_long(tvb,offset,stream_is_big_endian, boundary)); proto_tree_add_int(tree, hf_Quentin_ThumbnailListener_newThumbnail_offset, tvb, *offset-4, 4, get_CDR_long(tvb,offset,stream_is_big_endian, boundary)); proto_tree_add_int(tree, hf_Quentin_ThumbnailListener_newThumbnail_width, tvb, *offset-4, 4, get_CDR_long(tvb,offset,stream_is_big_endian, boundary)); proto_tree_add_int(tree, hf_Quentin_ThumbnailListener_newThumbnail_height, tvb, *offset-4, 4, get_CDR_long(tvb,offset,stream_is_big_endian, boundary)); u_octet4_loop_Quentin_ThumbnailListener_newThumbnail_data = get_CDR_ulong(tvb, offset, stream_is_big_endian, boundary); /* coverity[returned_pointer] */ item = proto_tree_add_uint(tree, hf_Quentin_ThumbnailListener_newThumbnail_data, tvb,*offset-4, 4, u_octet4_loop_Quentin_ThumbnailListener_newThumbnail_data); for (i_Quentin_ThumbnailListener_newThumbnail_data=0; i_Quentin_ThumbnailListener_newThumbnail_data < u_octet4_loop_Quentin_ThumbnailListener_newThumbnail_data; i_Quentin_ThumbnailListener_newThumbnail_data++) { proto_tree_add_int(tree, hf_Quentin_ThumbnailListener_newThumbnail_data, tvb, *offset-4, 4, get_CDR_long(tvb,offset,stream_is_big_endian, boundary)); } I've attached the full packet-quentin.c in case it helps. If I run this I get an error in the dissector Q_quentin Dissector Using GIOP API ident: 0 offset: 1073 width: 90 height: 72 Seq length of data: 6480 followed by.. Message: proto.c:3174: failed assertion "DISSECTOR_ASSERT_NOT_REACHED" It looks like the variable used in the loop is wrong. This needs a new variable creating. e.g. {&hf_Quentin_ThumbnailListener_newThumbnail_data_int, {"data","giop-q_quentin.ThumbnailListener.newThumbnail.data.int",FT_INT32,BASE_DEC,NULL,0x0,NULL,HFILL}}, and the loop changing to use this e.g. proto_tree_add_int(tree, hf_Quentin_ThumbnailListener_newThumbnail_data_int, tvb, *offset-4, 4, get_CDR_long(tvb,offset,stream_is_big_endian, boundary)); This only seems to be a problem when it is a sequence of longs. Other sequences look correct. I have also tried with the development build 1.11.2 and that fails in the same way. I would have a go at fixing it, but my Python isn't good enough to work out what to change.
You are receiving this mail because:
- You are watching all bug changes.
- Prev by Date: [Wireshark-bugs] [Bug 9531] IE chosen channel on Lb interface decoded incorrectly
- Next by Date: [Wireshark-bugs] [Bug 9533] New: Piping dumpcap to tshark results not stable
- Previous by thread: [Wireshark-bugs] [Bug 9531] IE chosen channel on Lb interface decoded incorrectly
- Next by thread: [Wireshark-bugs] [Bug 9533] New: Piping dumpcap to tshark results not stable
- Index(es):