chromium-dev — For developers of the Chromium framework or SPU's

Re: [Chromium-dev] More CRUT breakage

[Brian P. <bri...@tu...>]

OK, Looking at the code, glParametervCR(GL_WINDOW_SIZE_CR, GL_INT, 2, 
winsize) will only work for resizing the default window.  Note that 
the crHashtableSearch() call's last parameter is zero.  Yet another 
example of the old default window/context cruft.

You should probably use crWindowSize(windowID, width, height) instead.

Where are you making that call?  Do you have a Chromium window ID at 
that point?

-Brian


Mike Houston wrote:
> Hrmm.  Calling glParametervCR(GL_WINDOW_SIZE_CR, GL_INT, 2, winsize) 
> seems to have no effect anymore on the render/readback spu.
> 
> -Mike
> 
> Mike Houston wrote:
> 
>> psubmit_crut might be a bad example since we should probably handle 
>> reshape via CRUT/GLUT...  Still trying to track why Raptor is broken.
>>
>> -Mike
>>
>> Mike Houston wrote:
>>
>>> Window resizing is no longer working correctly.  Try crut_fan.conf 
>>> with resizable set to 1.  It seems that the changes to 
>>> render/readback have slightly borked CRUT, or at least the some of 
>>> the feedback paths.  Raptor now no longer runs correctly, so I'm 
>>> starting with the simple cases first.
>>>
>>> -Mike
>>>
>>>
>>> -------------------------------------------------------
>>> The SF.Net email is sponsored by: Beat the post-holiday blues
>>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>>> _______________________________________________
>>> Chromium-dev mailing list
>>> Chr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>>
>>
>>
>>
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 

Re: [Chromium-dev] More CRUT breakage

[Brian P. <bri...@tu...>]

Mike Houston wrote:
> Window resizing is no longer working correctly.  Try crut_fan.conf with 
> resizable set to 1.  It seems that the changes to render/readback have 
> slightly borked CRUT, or at least the some of the feedback paths.  
> Raptor now no longer runs correctly, so I'm starting with the simple 
> cases first.

Mike, give this patch a try.

I'd have to go back through my recent check-ins to know exactly why 
this stopped working.  But, the patch below fixes an oversight that's 
been present all along.

I'm tempted to add a 'track_window_size' option to the 
readback/binaryswap SPUs to supplement the 'resizable' option.  These 
two options would really control two distinct things.

-Brian

Re: [Chromium-dev] More CRUT breakage

[Mike H. <mho...@gr...>]

Hrmm.  Calling glParametervCR(GL_WINDOW_SIZE_CR, GL_INT, 2, winsize) 
seems to have no effect anymore on the render/readback spu.

-Mike

Mike Houston wrote:

> psubmit_crut might be a bad example since we should probably handle 
> reshape via CRUT/GLUT...  Still trying to track why Raptor is broken.
>
> -Mike
>
> Mike Houston wrote:
>
>> Window resizing is no longer working correctly.  Try crut_fan.conf 
>> with resizable set to 1.  It seems that the changes to 
>> render/readback have slightly borked CRUT, or at least the some of 
>> the feedback paths.  Raptor now no longer runs correctly, so I'm 
>> starting with the simple cases first.
>>
>> -Mike
>>
>>
>> -------------------------------------------------------
>> The SF.Net email is sponsored by: Beat the post-holiday blues
>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>> _______________________________________________
>> Chromium-dev mailing list
>> Chr...@li...
>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>
>
>

Re: [Chromium-dev] More CRUT breakage

[Mike H. <mho...@gr...>]

psubmit_crut might be a bad example since we should probably handle 
reshape via CRUT/GLUT...  Still trying to track why Raptor is broken.

-Mike

Mike Houston wrote:

> Window resizing is no longer working correctly.  Try crut_fan.conf 
> with resizable set to 1.  It seems that the changes to render/readback 
> have slightly borked CRUT, or at least the some of the feedback 
> paths.  Raptor now no longer runs correctly, so I'm starting with the 
> simple cases first.
>
> -Mike
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

[Chromium-dev] More CRUT breakage

[Mike H. <mho...@gr...>]

Window resizing is no longer working correctly.  Try crut_fan.conf with 
resizable set to 1.  It seems that the changes to render/readback have 
slightly borked CRUT, or at least the some of the feedback paths.  
Raptor now no longer runs correctly, so I'm starting with the simple 
cases first.

-Mike

Re: [Chromium-dev] ResizeWindow causes compile error in Darwin

[Brian P. <bri...@tu...>]

Christopher Waters wrote:
> A function called ResizeWindow was recently created in both 
> spu/readbackspu.c and spu/binaryswapspu.c
> This causes a compile error on Darwin because of a function of the same 
> name declared in one of the system headers included.
> 
> I changed all instances of ResizeWindow to WindowResize in the files on 
> my system, and it fixed the problem.  Now, does anyone know if -this- 
> would conflict with anything on the other platforms? ;)

How about just prefixing the functions with "readbackspu" and 
"binaryswapspu"?  Feel free to check in a fix.

-Brian

[Chromium-dev] ResizeWindow causes compile error in Darwin

[Christopher W. <cr...@ms...>]

A function called ResizeWindow was recently created in both 
spu/readbackspu.c and spu/binaryswapspu.c
This causes a compile error on Darwin because of a function of the same 
name declared in one of the system headers included.

I changed all instances of ResizeWindow to WindowResize in the files on 
my system, and it fixed the problem.  Now, does anyone know if -this- 
would conflict with anything on the other platforms? ;)

  -Chris

Re: [Chromium-dev] Re: Visual problems and GLX (again)

[Brian P. <bri...@tu...>]

OK, I think I've finally gotten to the bottom of all this.

I think we've just been getting lucky up until now, in terms of which 
GLX visuals are used for the various windows.

For example, in the crut_fan.conf demo:
1. The Readback SPUs do their depth compositing by using the
    stencil buffer.  So, the Render SPU that we composite into
    has a window and rendering context made from a GLX visual
    that has stencil planes.

2. Since we're using 'render_to_crut_window' the render SPU
    draws into the GLUT window instead of the stencil-capable
    window mentioned above.  HOWEVER, the GLUT window wasn't
    made with a stencil-capable visual!

Sometimes visuals have extra attributes (like stencil) that we didn't 
request.  That's when we got lucky.  Otherwise, we'd likely get 
BadDrawable errors.

Next, I found a bug in the psubmit_crut.c program: it never called
MakeCurrent()!  I don't know how that ever worked.

I've also updated the demo to explicitly create a new window, rather 
than rely on the default window.  This involved adding a new 
crutCreateWindow() function.

I'm gradually removing all remnants of the "default window" code from 
Chromium.  In the early Chromium days, there were no functions for 
creating windows, contexts and binding them, so a default rendering 
context and window were made up front and used everywhere.  That's 
been supported through today for compatiblity reasons.  But it 
sometimes causes problems.

The patch I posted before was a hack.  The Readback SPU, since it's 
derived from the Render SPU, should query 'default_visual'.  The 
Binary swap SPU too.

I'll check in my changes in a bit.

-Brian



Mike Houston wrote:
> That works.  Removing the assertion doesn't quite do what we want since 
> the render SPU still creates a bogus default window with the wrong 
> visuals.  For some reason, we have a situation in which we try to set 
> thing up before we have a window.
> 
> -Mike
> 
> Brian Paul wrote:
> 
>> Mike Houston wrote:
>>
>>> We seem to be back with issues getting correct visuals for certain 
>>> apps like Raptor.  I'm hitting an assertion failure because the 
>>> context->visBits are not matching window->visBits (assert fail on 
>>> line 797 of readbackspu.c).  This only seems to occur when running 
>>> CRUT based applications who do their window creation through CRUT.  
>>> crut_ring.conf and crut_fan.conf are simpiler cases that exhibit this 
>>> behavior.
>>>
>>> The context visbits are sane, but the window's visbits are zero (!).  
>>> It seems that CRUT got broken along the way.  My guess is that window 
>>> creation is failing oddly, but it's going to be awhile to track this 
>>> down.  I'm currently running on ATI hardware, but I'd wager things 
>>> are borked on Nvidia and 3DLabs as well.
>>>
>>> -Mike
>>
>>
>>
>> Mike, try this patch.
>>
>> diff -r1.21 readbackspu_init.c
>> 68a69
>> >       window->visBits = CR_RGB_BIT | CR_DEPTH_BIT | CR_DOUBLE_BIT;
>>
>> Or, I think you can simply disable the assertion for the time being.
>>
>> I think I know what the real problem is.  I'll work on a proper fix.
>>
>> -Brian
> 
> 
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 

[Chromium-dev] Re: Visual problems and GLX (again)

[Mike H. <mho...@gr...>]

That works.  Removing the assertion doesn't quite do what we want since 
the render SPU still creates a bogus default window with the wrong 
visuals.  For some reason, we have a situation in which we try to set 
thing up before we have a window.

-Mike

Brian Paul wrote:

> Mike Houston wrote:
>
>> We seem to be back with issues getting correct visuals for certain 
>> apps like Raptor.  I'm hitting an assertion failure because the 
>> context->visBits are not matching window->visBits (assert fail on 
>> line 797 of readbackspu.c).  This only seems to occur when running 
>> CRUT based applications who do their window creation through CRUT.  
>> crut_ring.conf and crut_fan.conf are simpiler cases that exhibit this 
>> behavior.
>>
>> The context visbits are sane, but the window's visbits are zero (!).  
>> It seems that CRUT got broken along the way.  My guess is that window 
>> creation is failing oddly, but it's going to be awhile to track this 
>> down.  I'm currently running on ATI hardware, but I'd wager things 
>> are borked on Nvidia and 3DLabs as well.
>>
>> -Mike
>
>
> Mike, try this patch.
>
> diff -r1.21 readbackspu_init.c
> 68a69
> >       window->visBits = CR_RGB_BIT | CR_DEPTH_BIT | CR_DOUBLE_BIT;
>
> Or, I think you can simply disable the assertion for the time being.
>
> I think I know what the real problem is.  I'll work on a proper fix.
>
> -Brian

[Chromium-dev] Re: Visual problems and GLX (again)

[Brian P. <bri...@tu...>]

Mike Houston wrote:
> We seem to be back with issues getting correct visuals for certain apps 
> like Raptor.  I'm hitting an assertion failure because the 
> context->visBits are not matching window->visBits (assert fail on line 
> 797 of readbackspu.c).  This only seems to occur when running CRUT based 
> applications who do their window creation through CRUT.  crut_ring.conf 
> and crut_fan.conf are simpiler cases that exhibit this behavior.
> 
> The context visbits are sane, but the window's visbits are zero (!).  It 
> seems that CRUT got broken along the way.  My guess is that window 
> creation is failing oddly, but it's going to be awhile to track this 
> down.  I'm currently running on ATI hardware, but I'd wager things are 
> borked on Nvidia and 3DLabs as well.
> 
> -Mike

Mike, try this patch.

diff -r1.21 readbackspu_init.c
68a69
 >       window->visBits = CR_RGB_BIT | CR_DEPTH_BIT | CR_DOUBLE_BIT;

Or, I think you can simply disable the assertion for the time being.

I think I know what the real problem is.  I'll work on a proper fix.

-Brian

[Chromium-dev] Visual problems and GLX (again)

[Mike H. <mho...@gr...>]

We seem to be back with issues getting correct visuals for certain apps 
like Raptor.  I'm hitting an assertion failure because the 
context->visBits are not matching window->visBits (assert fail on line 
797 of readbackspu.c).  This only seems to occur when running CRUT based 
applications who do their window creation through CRUT.  crut_ring.conf 
and crut_fan.conf are simpiler cases that exhibit this behavior.

The context visbits are sane, but the window's visbits are zero (!).  It 
seems that CRUT got broken along the way.  My guess is that window 
creation is failing oddly, but it's going to be awhile to track this 
down.  I'm currently running on ATI hardware, but I'd wager things are 
borked on Nvidia and 3DLabs as well.

-Mike

Re: [Chromium-dev] broken context.c

[Brian P. <bri...@tu...>]

Christopher Waters wrote:
> well, broken on windows/darwin :)
> 
> Error:
> context.c: In function `stubMakeCurrent':
> context.c:997: error: structure has no member named `dpy'
> 
> Line:
> if (stub.trackWindowVisibility && window->type == CHROMIUM && 
> window->dpy) {
> 
> Shouldn't this have 'window->drawable' instead of 'window->dpy'?
> or, looking at what the body uses, should it be 'window->spuWindow'

Yes, you're right.  I checked in the change.  Thanks.

-Brian

[Chromium-dev] disparate colors using Windows->Onyx4

[<aac...@ad...>]

Hello Chromium community,
 
We are setting up Chromium to run (mothership and crappfaker) on a Windows box and the crserver on an SGI Onyx 4 with IRIX. 

When running some applications, the colors that show-up on the Onyx 4 rendering nodes have disparate colors and apparent dithering.  Many OpenGL programs such as Atlantis, City, etc, do not have any color variations at all.  BUT, some important in-house applications and other third-party applications do not show the color-schemes one would expect.  Oceans that normally appear blue on a globe, might look purple, etc when passed through Chromium and displayed on the Onyx 4 crserver. 

Not all colors are off, but noticeably some are.     

I was wondering if anyone has seen this effect before?  I know I'd seen displays show all-white when textures could not be rendered due to video-card problems, but I haven't seen color-abnormalities like are appearing now.

The video cards on the 2x2 SGI display are not all the same.  Two of the video cards are Firegl GL X2 and two of the other video cards are Firegl GL X1.  The Windows box also has a Firegl GL X1. 

Some of the ideas to fix this problem have been:

Big-endian, Little-endian...perhaps going between Windows to Onyx results in some kind of color-transformation via the Big-endian, Little-endian of the color values?

We bought an identical Video card for the Windows machine, in the hopes that that would ensure identical color-map for both the Onyx and Windows machines.  Apparently that was not the issue either, as everything still has the same color difficulties.

Does the Windows box have one color-map, and the Onyx a different color map that is being referenced that would cause these problems?

Let me know if you have any ideas.

Thanks so much for your help,
Alicia

[Chromium-dev] disparate colors using Windows->Onyx4

[<aac...@ad...>]

Hello Chromium community,
  
We are setting up Chromium to run (mothership and crappfaker) on a Windows box and the crserver on an SGI Onyx 4 with IRIX.  

When running some applications, the colors that show-up on the Onyx 4 rendering nodes have disparate colors and apparent dithering.  Many OpenGL programs such as Atlantis, City, etc, do not have any color variations at all.  BUT, some important in-house applications and other third-party applications do not show the color-schemes one would expect.  Oceans that normally appear blue on a globe, might look purple, etc when passed through Chromium and displayed on the Onyx 4 crserver.  

Not all colors are off, but noticeably some are.      
 
I was wondering if anyone has seen this effect before?  I know I'd seen displays show all-white when textures could not be rendered due to video-card problems, but I haven't seen color-abnormalities like are appearing now. 
 
The video cards on the 2x2 SGI display are not all the same.  Two of the video cards are Firegl GL X2 and two of the other video cards are Firegl GL X1.  The Windows box also has a Firegl GL X1.  
 
Some of the ideas to fix this problem have been:

Big-endian, Little-endian...perhaps going between Windows to Onyx results in some kind of color-transformation via the Big-endian, Little-endian of the color values?

We bought an identical Video card for the Windows machine, in the hopes that that would ensure identical color-map for both the Onyx and Windows machines.  Apparently that was not the issue either, as everything still has the same color difficulties.

Does the Windows box have one color-map, and the Onyx a different color map that is being referenced that would cause these problems?

Let me know if you have any ideas.
 
Thanks so much for your help,
Alicia 
 

[Chromium-dev] broken context.c

[Christopher W. <cr...@ms...>]

well, broken on windows/darwin  :)

Error:
context.c: In function `stubMakeCurrent':
context.c:997: error: structure has no member named `dpy'

Line:
if (stub.trackWindowVisibility && window->type == CHROMIUM && 
window->dpy) {

Shouldn't this have 'window->drawable' instead of 'window->dpy'?
or, looking at what the body uses, should it be 'window->spuWindow'

  -Chris

Re: [Chromium-dev] Running in IRIX64 version 6.5

[Samuel T. <sam...@en...>]

Hi,

Le lun 29 nov 2004 à 16:17:35 -0500, aac...@ad... a tapoté sur son clavier :
> I am trying to run Chromium using SGI IRIX64, IRIX version 6.5.  I have downloaded and installed gnumake 3.80, python2-2.1.1, and GLUT-3.7.  

This version of python is too old for having getaddrinfo().

> AttributeError: 'socket' module has no attribute 'getaddrinfo'
> node11 34#

Regards,
Samuel

[Chromium-dev] Running in IRIX64 version 6.5

[<aac...@ad...>]

Hello Chromium Community,

I am trying to run Chromium using SGI IRIX64, IRIX version 6.5.  I have downloaded and installed gnumake 3.80, python2-2.1.1, and GLUT-3.7.  

When I compile Chromium, there are more than 50 warning messages that display.  Is this normal compiler output?  

When I try to run atlantis through Chromium I get the following:

node11 33# python crdemo.conf atlantis
This is Chromium, Version 1.7


MOTHERSHIP EXCEPTION!  TERRIBLE!
Traceback (most recent call last):
  File "../server/mothership.py", line 902, in Go
    for res in socket.getaddrinfo(None, PORT, socket.AF_UNSPEC, socket.SOCK_STREAM, 0, socket.AI_PASSIVE):
AttributeError: 'socket' module has no attribute 'getaddrinfo'
node11 34#

Has anyone encountered this error message before about the socket module not having the attribute 'getaddrinfo'?

Thanks for your help,
Alicia Crouch

Re: [Chromium-dev] Confusion with how the faker works

[Brian P. <bri...@tu...>]

Christopher Waters wrote:
> I think I've been confused on what goes on when chromium 'fakes' an 
> application.
> 
> I was under the impression that with Chromium, I could run a 
> non-chromium-aware application in a Chromium configuration (sort-first, 
> sort-last, etc), but all I have seen Chromium do with the application's 
> OpenGL stream is pass it straight to the native OpenGL renderer...  
> Inspecting opengl_stub, it seems that the only time a chromium context 
> is made is when crCreateContext is called, which a regular application 
> wouldn't call.

Note that crCreateContext calls stubCreateContext.

If your application uses GLX or WGL, the glX/wglCreateContext() 
functions call it too.

-Brian

[Chromium-dev] Confusion with how the faker works

[Christopher W. <cr...@ms...>]

I think I've been confused on what goes on when chromium 'fakes' an 
application.

I was under the impression that with Chromium, I could run a 
non-chromium-aware application in a Chromium configuration (sort-first, 
sort-last, etc), but all I have seen Chromium do with the application's 
OpenGL stream is pass it straight to the native OpenGL renderer...  
Inspecting opengl_stub, it seems that the only time a chromium context 
is made is when crCreateContext is called, which a regular application 
wouldn't call.

Am I missing something in all of this?

  -Chris

Re: [Chromium-dev] Re: Chromium 1.8 release?

[Brian P. <bri...@tu...>]

Anthony Steed wrote:
> 
> There are some minor issues compiling the latest CVS on Visual Studio 
> .Net 2003.
> 
> - calllists.c should include "chromium.h" not <GL/gl.h> to work on Win32.

Fixed.


> - I get a problem with crInfo not being discovered when linking various 
> components. I didn't look at this, but just replaced them with calls to 
> crDebug. This affected the following files:
>  ./crserverlib/server_main.c
>  ./crserverlib/server_stream.c
>  ./crserverlib/server_tiles.c
>  ./spu/tilesort/tilesortspu_config.c
>  ./util/error.c

I added crInfo to util/util.def to fix that.

> 
> A request for 1.8 - can all core header files get C++ wrappers (most do, 
> but some do not). I did this on a version a few months ago. This enabled 
> us to write an SPU which got headtracking data from the gadgeteer module 
> of VRJuggler. This allowed us to take a desktop application and show it 
> in head-tracked stereo. So far this was done just for a couple of PC 
> servers, but hopefully we will demonstrate it for our SGI-based 
> CAVE-like system in the next couple of months.

If you send a patch for this, I'll check it in.

-Brian

[Chromium-dev] Re: Chromium 1.8 release?

[Anthony S. <A....@cs...>]

There are some minor issues compiling the latest CVS on Visual Studio 
.Net 2003.

- calllists.c should include "chromium.h" not <GL/gl.h> to work on Win32.
- I get a problem with crInfo not being discovered when linking various 
components. I didn't look at this, but just replaced them with calls to 
crDebug. This affected the following files:
  ./crserverlib/server_main.c
  ./crserverlib/server_stream.c
  ./crserverlib/server_tiles.c
  ./spu/tilesort/tilesortspu_config.c
  ./util/error.c

A request for 1.8 - can all core header files get C++ wrappers (most do, 
but some do not). I did this on a version a few months ago. This enabled 
us to write an SPU which got headtracking data from the gadgeteer module 
of VRJuggler. This allowed us to take a desktop application and show it 
in head-tracked stereo. So far this was done just for a couple of PC 
servers, but hopefully we will demonstrate it for our SGI-based 
CAVE-like system in the next couple of months.

Anthony

--

>  I think it would be nice to wrap up and release Chromium 1.8 sometime
>  this month.  The last release was back in April.
>  
>  I"ll try to start running through the test plan in my spare time.
>  Let"s try to avoid checking in any potentially disruptive changes.
>  Speak up if you have anything that should be included in 1.8.
>  
>  -Brian
>  

[Chromium-dev] The performance of Chromium on WinXP?

[Guodong <yg...@ma...>]

Hi, 

I have run some opengl-demos on WindowsXP and the graphics card is Nvidia
GeForce 5800. However, the performance of OpenGL application degenerates
greatly on WindowsXP than on Linux. For example, the atlantis demo only can
be rendered at 82 Frames/Second on Windows. It seems that the opengl
application works without hardware acceleration. Does anyone know how to
solve this problem?

Best Wishes

guodong

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

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

[Brian P. <bri...@tu...>]

Joel Welling wrote:
> we...@st... said:
> 
>>bri...@tu... 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 
> 
> 
> we...@st... 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

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

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

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

we...@st... 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