Wireshark-bugs: [Wireshark-bugs] [Bug 12729] New: Buildbot crash output: fuzz-2016-08-09-999.pca
Date: Tue, 09 Aug 2016 22:50:03 +0000
Bug ID 12729
Summary Buildbot crash output: fuzz-2016-08-09-999.pcap
Product Wireshark
Version unspecified
Hardware x86-64
URL https://www.wireshark.org/download/automated/captures/fuzz-2016-08-09-999.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:

https://www.wireshark.org/download/automated/captures/fuzz-2016-08-09-999.pcap

stderr:
Input file: /home/wireshark/menagerie/menagerie/0000.cap

Build host information:
Linux wsbb04 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux
Distributor ID:    Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:    16.04
Codename:    xenial

Buildbot information:
BUILDBOT_REPOSITORY=ssh://wireshark-buildbot@code.wireshark.org:29418/wireshark
BUILDBOT_WORKERNAME=fuzz-test
BUILDBOT_BUILDNUMBER=31
BUILDBOT_URL=http://buildbot.wireshark.org/wireshark-2.2/
BUILDBOT_BUILDERNAME=Fuzz Test
BUILDBOT_GOT_REVISION=4db76ba54bb068107f890fbcf3bb2aa45f1aa8e3

Return value:  0

Dissector bug:  0

Valgrind error count:  1



Git commit
commit 4db76ba54bb068107f890fbcf3bb2aa45f1aa8e3
Author: Guy Harris <guy@alum.mit.edu>
Date:   Mon Aug 8 19:13:11 2016 -0700

    Use -r rather than -i for the "via stdin" tests.

    TShark, at least when running in one-pass mode, now supports reading
    from the standard input if the file format is one that *can* be read
    purely sequentially; both pcap and pcapng can be read purely
    sequentially (unlike, for example, Microsoft Network Monitor format,
    where you have to read the frame table, at the end of the file, before
    you can read the frames, meaning you have to seek backwards, which you
    can't do on a pipe).

    Using -r 1) tests the "read from standard input" path, which we should
    do in versions that support it, and 2) means we can check whether, for
    the crashes we're seeing on 32-bit Windows 8.1, it's a problem with
    reading from the standard input in general, or just a problem with
    *capturing* from the standard input.

    Change-Id: I67da34de43f47dd8c63fa2f2072be41148cfe5a7
    Reviewed-on: https://code.wireshark.org/review/16968
    Reviewed-by: Guy Harris <guy@alum.mit.edu>
    (cherry picked from commit 8a141febc849c36dc40d4da2a39318f8f8856091)
    Reviewed-on: https://code.wireshark.org/review/16969


==1044== Memcheck, a memory error detector
==1044== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==1044== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==1044== Command:
/home/wireshark/builders/wireshark-2.2-fuzz/fuzztest/install/bin/tshark -nr
/fuzz/buildbot/fuzztest/valgrind-fuzz-2.2/fuzz-2016-08-09-999.pcap
==1044== 
==1044== 
==1044== HEAP SUMMARY:
==1044==     in use at exit: 1,506,817 bytes in 39,778 blocks
==1044==   total heap usage: 265,134 allocs, 225,356 frees, 30,562,021 bytes
allocated
==1044== 
==1044== LEAK SUMMARY:
==1044==    definitely lost: 332,998 bytes in 150 blocks
==1044==    indirectly lost: 728,056 bytes in 30,033 blocks
==1044==      possibly lost: 0 bytes in 0 blocks
==1044==    still reachable: 445,763 bytes in 9,595 blocks
==1044==         suppressed: 0 bytes in 0 blocks
==1044== Rerun with --leak-check=full to see details of leaked memory
==1044== 
==1044== For counts of detected and suppressed errors, rerun with: -v
==1044== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1)

[ no debug trace ]


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