https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6898
Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jeff.morriss.ws@xxxxxxxxx
Summary|Buildbot crash output: |RTMPT OutOfMemory -
|fuzz-2012-02-13-31228.pcap |Buildbot crash output:
| |fuzz-2012-02-13-31228.pcap
--- Comment #2 from Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> 2012-03-18 18:48:55 PDT ---
The problem is the RTMPT dissector is allocating more memory than the fuzz
script thinks is reasonable. The RTMPT dissector has an upper limit on packet
sizes which apparently has been increased several times:
/* Native Bandwidth Detection (using the checkBandwidth(), onBWCheck(),
* onBWDone() calls) transmits a series of increasing size packets over
* the course of 2 seconds. On a fast link the largest packet can just
* exceed 256KB. */
/* #define RTMPT_MAX_PACKET_SIZE 131072 */
/* #define RTMPT_MAX_PACKET_SIZE 262144 */
#define RTMPT_MAX_PACKET_SIZE 524288
The fuzz script already allows 500,000 kbytes of memory usage so I'm hesitant
to raise the limit. I guess it's just that the source capture is long enough
that it's generating lots of big-but-less-than-524,288 allocations (well,
actually the source capture's only 850 kbytes long).
Not sure what to do about this. Maybe RTMPT needs to limit its *total* memory
usage. Or a preference for that max packet size (with a low default)?
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.