[bugzilla-daemon@xxxxxxxxxxxxx]

Bug ID	10095
Summary	Buildbot crash output: fuzz-2014-05-08-27950.pcap
Classification	Unclassified
Product	Wireshark
Version	unspecified
Hardware	x86-64
URL	http://www.wireshark.org/download/automated/captures/fuzz-2014-05-08-27950.pcap
OS	Ubuntu
Status	CONFIRMED
Severity	Major
Priority	High
Component	Dissection engine (libwireshark)
Assignee	bugzilla-admin@wireshark.org
Reporter	buildbot-do-not-reply@wireshark.org

Problems have been found with the following capture file:

http://www.wireshark.org/download/automated/captures/fuzz-2014-05-08-27950.pcap

stderr:
Input file: /home/wireshark/menagerie/menagerie/1277-bt.log

Build host information:
Linux wsbb04 3.2.0-61-generic #92-Ubuntu SMP Mon Mar 31 23:47:59 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux
Distributor ID:    Ubuntu
Description:    Ubuntu 12.04.4 LTS
Release:    12.04
Codename:    precise

Buildbot information:
BUILDBOT_REPOSITORY=ssh://wireshark-buildbot@code.wireshark.org:29418/wireshark
BUILDBOT_BUILDNUMBER=2747
BUILDBOT_URL=http://buildbot.wireshark.org/trunk/
BUILDBOT_BUILDERNAME=Clang Code Analysis
BUILDBOT_SLAVENAME=clang-code-analysis
BUILDBOT_GOT_REVISION=f3b631668bc35db2acac25d9c537f02d6c143e15

Return value:  0

Dissector bug:  0

Valgrind error count:  283



Git commit
commit f3b631668bc35db2acac25d9c537f02d6c143e15
Author: Evan Huus <eapache@gmail.com>
Date:   Tue May 6 21:45:16 2014 -0400

    Use a strong hash function for ethernet addresses.

    The capture for bug 10078 caused the buildbot to time out; callgrind
revealed an
    enourmous amount of time being spent looking up ethernet addresses. The
previous
    code cast each address (6 bytes) to a guint64 (8 bytes) then used the
built-in
    g_int64_hash. Unfortunately, g_int64_hash is an *awful* hash function - it
    produces a 4-byte hash by simply discarding the upper 4 bytes of its input.

    For the capture file in question this strategy (which effectively ignores
the
    upper two bytes of each ethernet address) produced an astounding number of
    collisions, leading to the terrible running-time.

    Use wmem_strong_hash directly on the 6-byte address instead, which saves us
a
    bunch of useless casting and bit-twiddling and produces a much better hash
    distribution. This shaves 20% off the time to tshark-with-tree the capture
file
    in question *despite* a substantially more expensive hash function
    (wmem_strong_hash is not exactly fast compared to g_int64_hash).

    Bug:10078
    Change-Id: I8e81cbc478e6394ec3a8efe39eec08f680a55609
    Reviewed-on: https://code.wireshark.org/review/1543
    Reviewed-by: Anders Broman <a.broman58@gmail.com>


Command and args: ./tools/valgrind-wireshark.sh -T

==13827== Memcheck, a memory error detector
==13827== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==13827== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==13827== Command:
/home/wireshark/builders/trunk-clang-ca/clangcodeanalysis/install/bin/tshark
-Vx -nr
/fuzz/buildbot/clangcodeanalysis/valgrind-fuzz/fuzz-2014-05-08-27950.pcap
==13827== 
==13827== Conditional jump or move depends on uninitialised value(s)
==13827==    at 0x65E18E2: uint_to_str_back (to_str.c:1173)
==13827==    by 0x65C26EA: fill_label_number (proto.c:6097)
==13827==    by 0x65CB686: proto_item_fill_label (proto.c:5779)
==13827==    by 0x65C027D: proto_tree_print_node (print.c:186)
==13827==    by 0x65C1BCB: proto_tree_children_foreach (proto.c:629)
==13827==    by 0x65C015D: proto_tree_print_node (print.c:241)
==13827==    by 0x65C1BCB: proto_tree_children_foreach (proto.c:629)
==13827==    by 0x65BF225: proto_tree_print (print.c:153)
==13827==    by 0x413420: print_packet (tshark.c:3939)
==13827==    by 0x414472: process_packet (tshark.c:3551)
==13827==    by 0x40BF82: main (tshark.c:3327)
==13827== 
==13827== 
==13827== HEAP SUMMARY:
==13827==     in use at exit: 1,222,378 bytes in 29,740 blocks
==13827==   total heap usage: 304,781 allocs, 275,041 frees, 35,371,823 bytes
allocated
==13827== 
==13827== LEAK SUMMARY:
==13827==    definitely lost: 9,323 bytes in 648 blocks
==13827==    indirectly lost: 36,424 bytes in 49 blocks
==13827==      possibly lost: 0 bytes in 0 blocks
==13827==    still reachable: 1,176,631 bytes in 29,043 blocks
==13827==         suppressed: 0 bytes in 0 blocks
==13827== Rerun with --leak-check=full to see details of leaked memory
==13827== 
==13827== For counts of detected and suppressed errors, rerun with: -v
==13827== Use --track-origins=yes to see where uninitialised values come from
==13827== ERROR SUMMARY: 283 errors from 1 contexts (suppressed: 3 from 3)

[ no debug trace ]

---

      You are receiving this mail because:

• You are watching all bug changes.