[bugzilla-daemon@xxxxxxxxxxxxx]

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.