From: Julie A. S. <jul...@ya...> - 2004-04-20 19:16:49
|
I realize debugging the large application would be very difficult, but how would I go about showing the problem occurs with a smaller test case? Wouldn't I need to have an idea, even if it was a broad idea, of what was causing the problem? I guess what I am trying to understand is how I, or anyone for that matter, could reproduce a problem on a smaller scale, without knowing what triggers the problem to occur in the first place, which is in turn the ultimate goal of scaling it down. Have you done anything like this before? Any ideas? Also, what information and/or data would be needed to reproduce a problem? Would texture data & the openGL stream captured with the print spu be enough to work with? Or would the application also be needed? Anything else? Sorry for all the questions, but I really want to get a fix for this issue. Thanks again for all of your input! -Julie Brian Paul <bri...@tu...> wrote: I'd need texture data. Anyway, it's _very_ difficult to debug something like this in a huge application. I'd have to reproduce the problem with a smaller test case. -Brian 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 the > 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 > > */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 working > > 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 my > > 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 Chromium. > > Could something in the application i am running be the cause? > > > > I was hoping it was the fact that the application was not calling > > 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 particular? > > Thanks > > Julie --------------------------------- Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ |