Wireshark-bugs: [Wireshark-bugs] [Bug 11299] New: Buildbot crash output: fuzz-2015-06-22-29338.p

Date: Tue, 23 Jun 2015 11:30:03 +0000
Bug ID 11299
Summary Buildbot crash output: fuzz-2015-06-22-29338.pcap
Product Wireshark
Version unspecified
Hardware x86-64
URL https://www.wireshark.org/download/automated/captures/fuzz-2015-06-22-29338.pcap
OS Ubuntu
Status CONFIRMED
Severity Major
Priority High
Component Dissection engine (libwireshark)
Assignee [email protected]
Reporter [email protected]

Problems have been found with the following capture file:

https://www.wireshark.org/download/automated/captures/fuzz-2015-06-22-29338.pcap

stderr:
Input file:
/home/wireshark/menagerie/menagerie/13669-running12_00036_20150616114139.pcapng

Build host information:
Linux wsbb04 3.13.0-55-generic #92-Ubuntu SMP Sun Jun 14 18:32:20 UTC 2015
x86_64 x86_64 x86_64 GNU/Linux
Distributor ID:    Ubuntu
Description:    Ubuntu 14.04.2 LTS
Release:    14.04
Codename:    trusty

Buildbot information:
BUILDBOT_REPOSITORY=ssh://[email protected]:29418/wireshark
BUILDBOT_BUILDNUMBER=3260
BUILDBOT_URL=http://buildbot.wireshark.org/trunk/
BUILDBOT_BUILDERNAME=Clang Code Analysis
BUILDBOT_SLAVENAME=clang-code-analysis
BUILDBOT_GOT_REVISION=2895d58dc38321a72c82e1bf77d165ef4acbc73a

Return value:  0

Dissector bug:  0

Valgrind error count:  1



Git commit
commit 2895d58dc38321a72c82e1bf77d165ef4acbc73a
Author: Guy Harris <[email protected]>
Date:   Sat Jun 20 15:57:57 2015 -0700

    Call the "802.11 radio information" dissector for radio headers.

    Have dissectors of various forms of radio information headers in the
    packets fill in a struct ieee_802_11_phdr with radio information as
    appropriate, and call the "802.11 radio information" dissector rather
    than the raw 802.11 dissector.

    This means that the radio information can be found in a
    protocol-independent and encapsulation-independent form when you're
    looking at the packet; that information can be presented in a form
    somewhat easier to read than the raw metadata header format.

    It also enables having a single "radio information" tap that allows
    statistics to handle all different sorts of radio information
    encapsulation.

    In addition, it lets us clean up some of the arguments passed to the
    common 802.11 dissector routine, by having it pull that information from
    the struct ieee_802_11_phdr.

    Ensure that the right structure gets passed to that routine, and that
    all the appropriate parts of that structure are filled in.

    Rename the 802.11 radio protocol to "wlan_radio", rather than just
    "radio", as it's 802.11-specific.  Give all its fields "wlan_radio."
    names rather than "wlan." names.

    Change-Id: I78d79afece0ce0cf5fc17293c1e29596413b31c8
    Reviewed-on: https://code.wireshark.org/review/8992
    Reviewed-by: Guy Harris <[email protected]>


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

==16158== Memcheck, a memory error detector
==16158== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==16158== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright
info
==16158== Command:
/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/bin/tshark
-Vx -nr
/fuzz/buildbot/clangcodeanalysis/valgrind-fuzz/fuzz-2015-06-22-29338.pcap
==16158== 
==16158== 
==16158== HEAP SUMMARY:
==16158==     in use at exit: 2,363,460 bytes in 178,156 blocks
==16158==   total heap usage: 2,928,396 allocs, 2,750,240 frees, 212,257,692
bytes allocated
==16158== 
==16158== LEAK SUMMARY:
==16158==    definitely lost: 127,780 bytes in 15,692 blocks
==16158==    indirectly lost: 37,320 bytes in 53 blocks
==16158==      possibly lost: 0 bytes in 0 blocks
==16158==    still reachable: 2,198,360 bytes in 162,411 blocks
==16158==         suppressed: 0 bytes in 0 blocks
==16158== Rerun with --leak-check=full to see details of leaked memory
==16158== 
==16158== For counts of detected and suppressed errors, rerun with: -v
==16158== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

[ no debug trace ]


You are receiving this mail because:
  • You are watching all bug changes.