Re: [Chromium-dev] Fix to comm buffer leak for upstream-going messages

[Joel W. <we...@st...>]

we...@ps... said:
> 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?

bri...@tu... said:
> 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? 

Yes, I do have a working version that avoids your assert failure by putting 
the crTeacFree() code in crTeacRecv() after crNetDispatch().  The architecture 
still confuses me, though.  I would have thought crFooRecv() would return a 
CRMessage from interface Foo, and crNetRecv() would cycle through the 
interfaces getting, dispatching, and disposing of those messages.  Maybe this 
had something to do with the need to immediately receive an upstream-going 
message after dispatching downstream-going messages containing glGet... and 
the like.  It certainly does look like the crFooFree() call that follows 
crNetDispatch in crFooRecv should be moved to crNetDispatch, though, since 
it's common to all interfaces.

In any case, I'm OK- my application is running and the Teac buffers are 
getting freed, and that version of the changes has been checked in.

-Joel