[reSIProcate] resiprocate crash due to no free memory when receiving sip message with large header

[Byron Campen]

On Jul 11, 2008, at 11:50 PM, Alan Hawrylyshen wrote:

>
> On Jul 11, 2008, at 15:25 , Byron Campen wrote:
>
>> 	Ok, I have committed the fix, plus some other fixes. Please take  
>> the code on head for a spin and see if it handles your testing.
>>
>> Best regards,
>> Byron Campen
>>
>
> Byron,
>
> THanks for that.
> Seems reasonable except for the catch(std::bad_alloc&) ... I'm not  
> sure it's good MoJo to catch that. Given our amazing reliance on the  
> heap, a failure to allocate is a serious problem. I'm more tempted  
> to subclass the allocator and create 'transport buffers' as a type  
> that we can define an allocator for. Then we can put a limit on the  
> amount of memory in play for transport buffers WITHOUT jepordizing  
> the operation of the rest of the stack. I realize this is something  
> of a change, but it is far safer than implementing a catch of  
> bad_alloc when std::operator new(size_t) the the thrower....
>

	Sure, but what is there is better than nothing; we even free up a  
good chunk of memory when this code gets hit. We can refine this  
later. I just want to have something I can backport to 1.3 today.

Best regards,
Byron Campen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20080714/07819b6a/attachment.bin>