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

[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?

-Joel





-------------------------------------------------------
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