Menu
▾
▴
[Chromium-dev] Re: How to reproduce "Out of memory" situation
|
From: Brian P. <bri...@tu...> - 2004-04-20 20:08:44
|
Well, there's no substitute for experience when debugging. I've been=20 doing this stuff for over ten years - that helps, but it's hard to=20 distill that down into a few simple tips. We seem to have at least narrowed the problem down to texture images,=20 right? Well, try disabling all calls to glTexImage2D and glTexSubImage2D and=20 see what happens. The rendering will be wrong, but you can observe=20 the memory usage and see what happens. Another thing to do is to take a simple GLUT program and modify it so=20 its main drawing routine mimics your application's OpenGL usage. Have=20 it issue a similar sequence of glBindTexture, glTexImage, etc commands=20 and see what happens. Incidentally, there's some funny looking stuff in your LogApp.crlog=20 file. For example: BindTexture( GL_TEXTURE_2D, 65593 ) TexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, 9729 ) TexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, 9729 ) TexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, 33071 ) TexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, 33071 ) TexImage2D( GL_TEXTURE_2D, 0, 32855, 512, 512, 0, GL_RGBA,=20 GL_UNSIGNED_SHORT_5_5_5_1_EXT, 04FB7A44 ) BindTexture( GL_TEXTURE_2D, 65593 ) TexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, 9729 ) TexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, 9729 ) TexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, 33071 ) TexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, 33071 ) TexImage2D( GL_TEXTURE_2D, 0, 32855, 512, 512, 0, GL_RGBA,=20 GL_UNSIGNED_SHORT_5_5_5_1_EXT, 04FB7A44 ) BindTexture( GL_TEXTURE_2D, 65593 ) TexSubImage2D( GL_TEXTURE_2D, 0, 0, 0, 512, 512, GL_RGBA,=20 GL_UNSIGNED_SHORT_5_5_5_1_EXT, 0B140020 ) Finish( ) This amounts to specifying the same texture image three times in a=20 row. Any particular reason for that? Later, when the same texture object is bound prior to drawing a=20 triangle fan, the texture filter and wrap parameters are set yet again=20 to the same values: BindTexture( GL_TEXTURE_2D, 65593 ) TexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, 9729 ) TexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, 9729 ) TexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, 33071 ) TexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, 33071 ) Begin( GL_TRIANGLE_FAN ) [...] This leads me to think that the OpenGL coding is a bit sloppy so we=20 may be hitting an OpenGL sequence that's rather unusual in some way. -Brian Julie A. Smock wrote: > I realize debugging the large application would be very difficult, but=20 > how would I go about showing the problem occurs with a smaller test cas= e? > Wouldn't I need to have an idea, even if it was a broad idea, of what=20 > was causing the problem? I guess what I am trying to understand is how=20 > I, or anyone for that matter, could reproduce a problem on a smaller=20 > scale, without knowing what triggers the problem to occur in the first=20 > place, which is in turn the ultimate goal of scaling it down. > Have you done anything like this before? Any ideas? > =20 > Also, what information and/or data would be needed to reproduce a=20 > problem? Would texture data & the openGL stream captured with the print= =20 > spu be enough to work with? Or would the application also be needed?=20 > Anything else? > =20 > Sorry for all the questions, but I really want to get a fix for this is= sue. > Thanks again for all of your input! > =20 > -Julie > =20 > */Brian Paul <bri...@tu...>/* wrote: >=20 > I'd need texture data. Anyway, it's _very_ difficult to debug > something like this in a huge application. I'd have to reproduce th= e > problem with a smaller test case. >=20 > -Brian >=20 > Julie A. Smock wrote: > > Would it be possible to reproduce the problem using the openGL > stream > > produced by my application? I posted the streams captured using = the > > Print SPU on my ftp site. They run from the application start-up= and > > through till the out of memory crash. These are the links: > > ftp://208.253.108.10/LogApp.crlog.gz > > - from the application packed to my chromium server > > __ > > ___ftp://208.253.108.10/LogServer.crlog.gz_ > > - tilesorted to the displays > > > > Is there anything else I can do to help you reproduce/recreate t= he > > problem? I was worried that you would be unable to reproduce the > problem! > > from these streams because you do not have the actual texture > data that > > are referenced in the stream. Is that right, that you would need= the > > texture data to reproduce the error? The problem is, it would be > very > > difficult for me to provide this texture data to you. > > > > - Julie > >=20 > > */Brian Paul /* wrote: > > > > It's probably a bug in Chromium related to buffer management, > but I'm > > kind of stuck since I can't reproduce it here. > > > > -Brian > > > > Julie A. Smock wrote: > > > From your explanation and tests, it sounds like Chromium is wo= rking > > > just fine. But if this is the case, then I must assume it is > > > something inherent in the application I am running. > > > The thing I still don't understand is how it could be solely m= y > > > application, since I see just a slight increase in memory when > I run > ! > > it on its own, but such a drastic one when I run through Chro= mium. > > > Could something in the application i am running be the cause? > > > > > > I was hoping it was the fact that the application was not call= ing > > > glDeleteTexture(), but I no longer think that is a viable > > > explanation because the application runs fine when not running= *> > > through Chromium. > > > Any suggestions on where to start looking? Any files in partic= ular? > > > Thanks > > > Julie >=20 > -----------------------------------------------------------------------= - > Do you Yahoo!? > Yahoo! Photos: High-quality 4x6 digital prints for 25=A2=20 > <http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=3D23765/*http://photos= .yahoo.c=20 > om/ph/print_splash> |