| 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 |
[email protected]
|
| Reporter |
[email protected]
|
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://[email protected]: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 <[email protected]>
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 <[email protected]>
(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.