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

 
 

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

Submitted by:  None
Submitted on:  Sat 26 Sep 2009 09:53:14 PM UTC  
 
Category: NonePriority: 5 - Normal
Severity: 4 - ImportantStatus: Postponed
Privacy: PublicAssigned to: fsck <fsck>
Originator Email: -unavailable-Open/Closed: Open
Operating System: Mac OS

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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 AdministratorIn charge of this item.
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 AdministratorIn charge of this item.
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:
rtmp://peakbroadcasting.streamguys.org/live/kcix

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://peakbroadcasting.streamguys.org/live/kcix" -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: http://www.kiss1033.com>
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: >
Metadata:
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
website http://www.kiss1033.com
creationdate Tuesday, September 22, 2009 05:16:10 UTC
artist BREAK
title 9/26/2009 3:47:53 PM
url
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.

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 24 Oct 2009 05:13:43 PM UTCfsckAssigned toNone=>fsck
      StatusNone=>Postponed

    Back to the top


    Powered by Savane 3.1-cleanup