Wireshark · Wireshark-dev: Re: [Wireshark-dev] Wireshark runtime messages we don't want to see

[Alexis La Goutte <alexis.lagoutte@xxxxxxxxx>]

On Thu, Apr 30, 2015 at 10:44 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:

On Apr 30, 2015, at 9:58 AM, Joerg Mayer <jmayer@xxxxxxxxx> wrote:

> jmayer@egg epan$ wireshark
> QMetaObject::connectSlotsByName: No matching signal for on_actionExternalMenuItem_triggered()

About this warning, i coming from eeed4d1121f122aa5579153872193b9a91d8ad52

We don't use on_xxx_triggered() function, it is a magic Qt function to automatically "link" signal and slot ( http://qtway.blogspot.no/2010/08/automatic-connections-using-qt-signals.html )

rename function, it will be fix the warning

> ../../asn1/c1222/packet-c1222-template.c:1427:3: runtime error: null pointer passed as argument 1, which is declared to never be null
> ../../asn1/c1222/packet-c1222-template.c:1427:3: runtime error: null pointer passed as argument 2, which is declared to never be null

That probably means that oid_string2encoded() failed.

Pascal Quantin's working on a fix for this:

        https://code.wireshark.org/review/8251

but presumably the failure means either that

        1) you specified an invalid (not a syntactically-valid OID) setting for the "Base OID to use for relative OIDs" preference for the C.1222 dissector

or

        2) you have no setting for it so that the string is null (which is, as far as I know, not a syntactically-valid OID)

and I strongly suspect it's 2) here, so perhaps that code should also special-case null strings.  (Ultimately, we should catch syntactically-invalid OIDs rather than just silently ignoring them.)

Hopefully, the code also can handle a missing OID.

> 18:37:43          Dbg  plugin_dir: /opt/test/lib/wireshark/plugins/1.99.6
> ERROR: Cannot connect to ADB: Connection refused
> INFO: Please check that adb daemon is running.
> ==> after double clicking the wlan0 interface
> /home/jmayer/work/wireshark/git/wsutil/sign_ext.h:53:33: runtime error: left shift of negative value -1

So is this presumably from C99's

        6.5.7 Bitwise shift operators

                ...

                The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. ... *If E1 has a signed type and nonnegative value, and E1 × 2^E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined.*

The intent of the shifts in the "val |= (-1 << no_of_bits)" in

        /* sign extension routines */

        static inline guint32
        ws_sign_ext32(guint32 val, int no_of_bits)
        {
                g_assert (no_of_bits >= 0 && no_of_bits <= 32);

                if (no_of_bits == 0)
                        return val;

                if (val & (1 << (no_of_bits-1)))
                        val |= (-1 << no_of_bits);

                return val;
        }

        static inline guint64
        ws_sign_ext64(guint64 val, int no_of_bits)
        {
                g_assert (no_of_bits >= 0 && no_of_bits <= 64);

                if (no_of_bits == 0)
                        return val;

                if (val & (G_GINT64_CONSTANT(1) << (no_of_bits-1)))
                        val |= (G_GUINT64_CONSTANT(-1) << no_of_bits);

                return val;
        }

is to generate a value with no_of_bits low-order zero bits and all the other bits 1, so that bits in the 32-bit or 64-bit value above the sign bit in the no_of_bits-bit value are set for negative values.

(Yes, we're assuming 2's complement, but I don't think this is the only place, and if you're trying to get Wireshark to run on a Unisys ClearPath Dorado system, trust me, that's not going to be your biggest problem. :-))

We might as well just use (G_GUINT64_CONSTANT(0xFFFFFFFFFFFFFFFF) << no_of_bits) - and, while we're at it, use (0xFFFFFFFF << no_of_bits) in the 32-bit case.

Fixed in I62220808058cb93f83329c1916b888a2067d524c.

> /home/jmayer/work/wireshark/git/epan/proto.c:9154:47: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'


That should now be fixed by I95cf5ce53aa3b94ccb9f246d31863715bb682409, if I understand the complaint - bitmasks for testing individual bits should probably be given as "1U << xxx" rather than "1 << XXX" so that the type is "unsigned int".

There are probably other cases where that needs to be done.  The bit tests in the wsutil/sign_ext.h code above is one of them; that's also fixed by I62220808058cb93f83329c1916b888a2067d524c.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe