[Live-devel] MediaSink / Memory leak

[Brad O'Hearne]

Ross, 

I had another thought here -- and I open this to anyone else trying to use Live555 inside the scope of Xcode. My MediaSink subclass I implemented as a .cpp file, (as a matter of fact I had to do the same with my RTSPClient subclass, used a .cpp file), because if I attempted to use a .mm file (typical for compiling in C++ in Xcode), I received the following compilation error (as a result of Live555 header includes): 

Boolean.hh: Typedef redefinition with different types ('unsigned int' vs 'unsigned char')

This is presumably due to type definition conflicts between Objective C boolean-related declarations and those declared in Boolean.hh. As I went through the Live555 source and consulted Googlepalooza's returned forum posts on the matter, I was a bit skittish about tweaking anything as fundamental as a base type definition without knowing in more detail the possible ramifications. I'm sure the answer is probably a simple one, but Ross, you seem to have insight into the entire code-base, so if you or anyone else can advise on how to address this so as to make Live555 play nice in Xcode with Objective C, I'd greatly appreciate it. 

Bottom line, I'm wondering what effect this might be having on the runtime issue below. It is really the only nuance of environmental difference I can think of, other than use of Apple's LLVM and LLDB. 

Thanks, 

Brad

Brad O'Hearne
Founder / Lead Developer
Big Hill Software LLC
http://www.bighillsoftware.com

On Mar 6, 2012, at 3:31 PM, Brad O'Hearne wrote:

> Ross, 
> 
>>>     delete[] sPropRecords;
>>> 
>>> with the error that the "pointer being freed was not allocated".
>> 
>> I don't understand why you're getting an error here; the code looks OK.
> 
> Yeah, I know the feeling!  ;-) But it would seem more than an issue of style, it outright crashes the entire app...
> 
>> FYI, in C++ "delete[]"ing (or "delete"ing) a NULL pointer is not an error (it has no effect).
> 
> Yeah...I've been wondering if I'm dealing with some compiler nuance in part. I did that to see if it would have any marked effect on the outcome. 
> 
> The only way I can get a run that doesn't crash is to remove the 
> 
>>>     delete[] sPropRecords;
> 
> 
> line entirely, and as a result, the memory....
> 
> Brad
> 
> On Mar 6, 2012, at 3:16 PM, Ross Finlayson wrote:
> 
>>> This particular code snippet was taken directly from the Live555 H264VideoFileSink class implementation of its afterGettingFrame() method, so the exact code and usage context should be identical. 
>>> 
>>> Anyway, I have taken my app run it on Xcode, and this line pretty quickly crashes the app: 
>>> 
>>>     delete[] sPropRecords;
>>> 
>>> with the error that the "pointer being freed was not allocated".
>> 
>> I don't understand why you're getting an error here; the code looks OK.
>> 
>> 
>>> I then figured that there was something internal to the parseSPropParameterSets which might conditionally allocate sPropRecords. So I wrapped the delete in a conditional: 
>>> 
>>>     if (sPropRecords)
>>>     {
>>>         delete[] sPropRecords;
>>>     }
>>> 
>>> The error was the same
>> 
>> FYI, in C++ "delete[]"ing (or "delete"ing) a NULL pointer is not an error (it has no effect).
>> 
>> Ross Finlayson
>> Live Networks, Inc.
>> http://www.live555.com/
>> 
>> _______________________________________________
>> live-devel mailing list
>> live-devel at lists.live555.com
>> http://lists.live555.com/mailman/listinfo/live-devel
> 
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120306/2ff18316/attachment.html>