Re: Fix to comm buffer leak for upstream-going messages

Joel Welling wrote:
> [email protected] said:
> 
>>[email protected] said:
>>The above change to the pack SPU causes an assertion failure for me.
>>If you compile chromium with RELEASE=0 and test with crdemo.conf and
>>TCP/IP you'll see it.
>>If I find time later, I'll try to narrow down the cause.
>>-Brian 
> 
> 
> [email protected] said:
> 
>>OK, the conflict is happening because teac.c was written before the
>>days of  BufferPool stuff and was never updated.  I'm trying to figure
>>out how they  work now...
>>-Joel 
> 
> 
> I take it back- as far as I can tell Teac should be able to work just fine 
> without the use of BufferPools.  There doesn't seem to be any particular 
> requirement that every network interface manage buffers in this particular way.
> 
> However, Brian's assertion failure is certainly real.  It apparently happens 
> because a tcpip buffer gets freed twice with crBufferPoolPush().  This is 
> presumably happening because the code at tcpip.c:1015 frees pretty much all 
> messages, unlike the code in crNetDefaultRecv or in crTeacRecv.  Is the 
> convention supposed to be that each network interface's Recv function should 
> call crNetFree on the buffer after calling crNetDispatch?  If that's the case, 
> why doesn't crNetDispatch just do it, since the function of the message types 
> isn't supposed to depend on the network type over which they are sent?

I'm not really sure what the original intention was.  I'd have to 
spend some time reviewing the code to know.

I saw you checked in a change earlier, does that solve your problem?

-Brian


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click