Wireshark-bugs: [Wireshark-bugs] [Bug 9949] New: Buildbot crash output: fuzz-2014-04-02-29441.pc
Date: Thu, 03 Apr 2014 04:10:04 +0000
Bug ID 9949
Summary Buildbot crash output: fuzz-2014-04-02-29441.pcap
Classification Unclassified
Product Wireshark
Version unspecified
Hardware x86-64
URL http://www.wireshark.org/download/automated/captures/fuzz-2014-04-02-29441.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:

http://www.wireshark.org/download/automated/captures/fuzz-2014-04-02-29441.pcap

stderr:
Input file:
/home/wireshark/menagerie/menagerie/10964-iDEN_UMTS_SIM_read.pcapng.gz

Build host information:
Linux wsbb04 3.2.0-60-generic #91-Ubuntu SMP Wed Feb 19 03:54:44 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://[email protected]:29418/wireshark
BUILDBOT_BUILDNUMBER=2662
BUILDBOT_URL=http://buildbot.wireshark.org/trunk/
BUILDBOT_BUILDERNAME=Clang Code Analysis
BUILDBOT_SLAVENAME=clang-code-analysis
BUILDBOT_GOT_REVISION=a8e963709063ff7b7b36f319fa2827e9be0af2e9

Return value:  1

Dissector bug:  0

Valgrind error count:  -1



Git commit
commit a8e963709063ff7b7b36f319fa2827e9be0af2e9
Author: Bill Meier <[email protected]>
Date:   Mon Mar 31 23:12:20 2014 -0400

    Fix two bugs and do misc other minor changes;

    Bugs fixed:
     - col_...() should not be called under 'if (tree)';
     - proto_reg_handoff_pdc(): pdc tcp.port preference change was handled
incorrectly;

    Minor changes:
    - Move proto_reg_handoff...() to the end of the file as per convention;
    - new_register_dissector...() call not needed;
    - Remove some unneeded initializers;
    - 'xxx++' ==> 'xxx += 1' in a few instances;
    - widen a few variables (guint? ==> guint);
    - Add XXX comment about possible simplification of the code;
    - Remove unneeded #include <epan/reassemble.h>;
    - Reformat hf[] entries for readability;
    - Do whitespace changes;

    Change-Id: Ib9224f0c6392a45c19656a63bbac97fbaf3acc08
    Reviewed-on: https://code.wireshark.org/review/900
    Reviewed-by: Bill Meier <[email protected]>
    Tested-by: Bill Meier <[email protected]>


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

==24987== Memcheck, a memory error detector
==24987== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==24987== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==24987== Command:
/home/wireshark/builders/trunk-clang-ca/clangcodeanalysis/install/bin/tshark
-nr /fuzz/buildbot/clangcodeanalysis/valgrind-fuzz/fuzz-2014-04-02-29441.pcap
==24987== 

(process:24987): GLib-ERROR (recursed) **:
/build/buildd/glib2.0-2.32.4/./glib/gmem.c:165: failed to allocate 24
bytes==24987== 
==24987== HEAP SUMMARY:
==24987==     in use at exit: 108,795,290 bytes in 1,177,559 blocks
==24987==   total heap usage: 4,821,402 allocs, 3,643,841 frees, 249,244,064
bytes allocated
==24987== 
==24987== 
==24987==     Valgrind's memory management: out of memory:
==24987==        newSuperblock's request for 9420800 bytes failed.
==24987==        594350080 bytes have already been allocated.
==24987==     Valgrind cannot continue.  Sorry.
==24987== 
==24987==     There are several possible reasons for this.
==24987==     - You have some kind of memory limit in place.  Look at the
==24987==       output of 'ulimit -a'.  Is there a limit on the size of
==24987==       virtual memory or address space?
==24987==     - You have run out of swap space.
==24987==     - Valgrind has a bug.  If you think this is the case or you are
==24987==     not sure, please let us know and we'll try to fix it.
==24987==     Please note that programs can take substantially more memory than
==24987==     normal when running under Valgrind tools, eg. up to twice or
==24987==     more, depending on the tool.  On a 64-bit machine, Valgrind
==24987==     should be able to make use of up 32GB memory.  On a 32-bit
==24987==     machine, Valgrind should be able to use all the memory available
==24987==     to a single process, up to 4GB if that's how you have your
==24987==     kernel configured.  Most 32-bit Linux setups allow a maximum of
==24987==     3GB per process.
==24987== 
==24987==     Whatever the reason, Valgrind cannot continue.  Sorry.

[ no debug trace ]


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