mainflvstreamer - Support: sr #107043, Corruption when reading live...


sr #107043: Corruption when reading live stream results in HUGE memory allocations and eventual crash

Submitter:  None
Submitted:  Sat 26 Sep 2009 09:53:14 PM UTC
Category:  None Priority:  5 - Normal
Severity:  4 - Important Status:  Postponed
Privacy:  Public Assigned to:  fsck
Originator Email:  -email is unavailable- Open/Closed:  Open
Operating System:  Mac OS
* Mandatory Fields

Add a New Comment (Rich Markup)

Sat 14 Nov 2009 12:54:02 PM UTC, comment #2: 

Major new release of flvstreamer v1.9 is out. Let us know if it helps...

fsck <fsck>
Project Administrator
Sat 24 Oct 2009 05:13:43 PM UTC, comment #1: 

I've not been able to solve the parsing error yet because I cannot reproduce it from my IP ad I don't have access to OSX. I've put a workaround into 1.8l in SVN which will make the connection quit if it encounters a very large body size.

fsck <fsck>
Project Administrator
Sat 26 Sep 2009 09:53:14 PM UTC, original submission:  

Hi, I've found a live stream which is causing a crash in libRTMP and since I can't figure out how to file a bug for that, I figured here's just as good...

So here's the stream:

It appears from my own debugging and verbose output of flvstreamer that it correlates with a "metadata" event/message.  Usually packets directly following them start to have a type of 0x0, but not without a few packets that are read and whose size is interpreted to be something very large.  This causes allocation of HUGE amounts of memory to read the packet body which causes a crash (on the iPhone) and on my mac a massive memory use (and possibly leak? though I'm not sure if it's leaking or just being allocated and deallocated).

I'm currently overwhelmed with other work so haven't been able to do too much to packet sniff, etc. to see exactly what's going on, but I can offer the commandline and the stream and what I've tried and someone else might test to see if they can reproduce it and might be better at debugging it than I am.

However, I do have one request, if at all possible and that's that any change be allowed to be under LGPL (since it's in the libRTMP code) and I've ported that to the iPhone. )  I guess if we can figure out what's wrong it might just be a couple lines of code to skip corrupt packets (though I think it's caused by bad parsing somehow).

Anyway, here's the command:

./flvstreamer -x -z -v -r "rtmp://" -o out.flv

And here's an example of the problem: from the output (what to look for).
DEBUG: type: 08, size: 177, TS: 110852 ms, abs TS: 0
DEBUG: type: 08, size: 202, TS: 110898 ms, abs TS: 0
DEBUG: GetNextMediaPacket, received: notify 502 bytes
DEBUG: Property: <Name:                  no-name., STRING: onMetaData>
DEBUG: Property: <Name:                  no-name., OBJECT>
DEBUG: Property: <Name:             audiodatarate, NUMBER: 32.00>
DEBUG: Property: <Name:           audiosamplerate, NUMBER: 44100.00>
DEBUG: Property: <Name:              audiocodecid, NUMBER: 10.00>
DEBUG: Property: <Name:              canSeekToEnd, BOOLEAN: FALSE>
DEBUG: Property: <Name:               audiodevice, STRING: Orban Optimod 1100 (212509059)>
DEBUG: Property: <Name:           metadatacreator, STRING: Orban Opticodec-PC 3.0 (os=Windows NT 5.1 Service Pack 3)>
DEBUG: Property: <Name:               description, STRING: Hi-Fi Internet Audio Stream>
DEBUG: Property: <Name:                      name, STRING: KISS 103.3 Boise's #1 Hit Music Station>
DEBUG: Property: <Name:                 createdby, STRING: Peak Broadcasting LLC>
DEBUG: Property: <Name:                   website, STRING:>
DEBUG: Property: <Name:              creationdate, STRING: Tuesday, September 22, 2009 05:16:10 UTC>
DEBUG: Property: <Name:                    artist, STRING: BREAK>
DEBUG: Property: <Name:                     title, STRING: 9/26/2009 3:47:53 PM>
DEBUG: Property: <Name:                       url, STRING: >
  audiodatarate         32
  audiosamplerate       44100
  audiocodecid          10
  canSeekToEnd          FALSE
  audiodevice           Orban Optimod 1100 (212509059)
  metadatacreator       Orban Opticodec-PC 3.0 (os=Windows NT 5.1 Service Pack 3)
  description           Hi-Fi Internet Audio Stream
  name                  KISS 103.3 Boise's #1 Hit Music Station
  createdby             Peak Broadcasting LLC
  creationdate          Tuesday, September 22, 2009 05:16:10 UTC
  artist                BREAK
  title                 9/26/2009 3:47:53 PM
DEBUG: type: 12, size: 502, TS: 110898 ms, abs TS: 0
DEBUG: type: 08, size: 170, TS: 16888113 ms, abs TS: 0
DEBUG: GetNextMediaPacket, unknown packet type received: 0x00

DEBUG: GetNextMediaPacket, unknown packet type received: 0x00

DEBUG: GetNextMediaPacket, unknown packet type received: 0x00


And the problem is that this line: (from rtmp.cpp )
if (packet.m_nBodySize > 0 && packet.m_body == NULL && !packet.AllocPacket(packet.m_nBodySize))

calls AllocPacket with a HUGE body size, which allocates a giant buffer.

So, while I can think of workaround to prevent the crash (by saying anything over body size X just skips without allocation) the problem is there's an underlying error that's causing this, so that's much better to figure out and fix...

Let me know if you need any more info (and yes, using my slightly modified version of libRTMP from trunk in XBMC has the same issue so it's not something specific to my port or flvstreamer's modifications.

Hope someone can help.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by fsck (Posted a comment)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.





    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-10-24 fsck Assigned toNone fsck
        StatusNone Postponed

    Back to the top

    Powered by Savane 3.11