AMD fglrx 8.42.3 leaking gobs of memory in OpenGL apps - any known workaround ?

[Malikith]

Hey, good eyes

I simply did a quick test running glxgears under valgrind (via "$ valgrind --tool=memcheck --leak-check=yes glxgears"). After only 4 glxgears "iterations" (the poor FPS are because of running under valgrind, of course) valgrind gave up for more than 10000000 detected errors and told me to "Go fix your program!"

The result is posted in the following comment (due to size constraints here). I omitted the startup output, and all those nearly identical "Invalid write of size 1"-Reports but the last one.

[Edit] This is on Lenovo Z61m / 2 GiB RAM / ATI X1400 / Gentoo AMD64 / Kernel 2.6.22 / GLIBC 2.7 / X.Org xserver 1.3 / fglrx 8.42.3

Suddenly, my hope in 8.43 just dropped like a rock.

[Snake]

Suddenly, my hope in 8.43 just dropped like a rock.

Don't get me wrong, I did not post this result to make anyone look bad, nor to demonstrate how "horrible" 8.42 is and that's about time to give up hope

It may well be the result of a single forgotten "free()" call, that simply gets multiplied with every frame (and as FPS drastically improved, so did the effect ).

We're on linux, where a bug is no "embarrassing taboo", but something that happens all the time (me being the exception, of course ). This is our operating system, so we are also resposible to improve it by helping tracking down and fixing those bugs. Perhaps AMD/ATI may even integrate a quick valgrind run into their QA procdures in future.

Let's help the devs, not bash them! It's a win-win, after all.

[Malikith]

Don't get me wrong, I did not post this result to make anyone look bad, nor to demonstrate how "horrible" 8.42 is and that's about time to give up hope

It may well be the result of a single forgotten "free()" call, that simply gets multiplied with every frame (and as FPS drastically improved, so did the effect ).

We're on linux, where a bug is no "embarrassing taboo", but something that happens all the time (me being the exception, of course ). This is our operating system, so we are also resposible to improve it by helping tracking down and fixing those bugs. Perhaps AMD/ATI may even integrate a quick valgrind run into their QA procdures in future.

Let's help the devs, not bash them! It's a win-win, after all.

Yeah I know, I never said that this doesn't happen. But its just one of many many problems with the driver. Hopefully that memory leak is not too difficult to fix. I guess I just expect a little more from a company that well, should had started working harder on Linux a long time ago.

I can't even begin on how many bugs there are. I've done my share of bug reporting but it seems the list grows faster and faster with every driver release hehe.

[oyvind]

<snip>

We're on linux, where a bug is no "embarrassing taboo", but something that happens all the time (me being the exception, of course ). This is our operating system, so we are also resposible to improve it by helping tracking down and fixing those bugs. Perhaps AMD/ATI may even integrate a quick valgrind run into their QA procdures in future.

Let's help the devs, not bash them! It's a win-win, after all.

I agree with you on this. And I'd certainly be willing to help in any way possible, but the one-way communication eventually gets really old.

I've reported a few bugs on http://ati.cchtml.com/, and find that I'm actually only talking to myself. I've always stated that I'm willing to help in further debugging, in the reports. There is no response, and all the bugs are still marked NEW, even though I've reported them a long time ago. So I stopped going there, because it feels utterly pointless. I just can't take that bugzilla seriously anymore.

I've also reported most of the stuff to AMD's customer feedback on the driver. But I have no idea if my reports are actually being looked at.

Then there's the Phoronix forums, but I don't know if any AMD devs are present and looking around.

[Snake]

I agree with you on this. And I'd certainly be willing to help in any way possible, but the one-way communication eventually gets really old.

I've reported a few bugs on http://ati.cchtml.com/, and find that I'm actually only talking to myself. <--snip-->

Same for me

The sad thing is that on this forum alone there are already lots of people that put their energy and knowledge into testing, trying to figure and report what exactly is going wrong and helping others. But without a "living" bug tracker all those efforts remain scattered pieces floating around, being discussed over and over again in variations without anyone being able to really catch all available info for the bug at hand.

I wonder if AMD/ATI could be convinced to actively use http://ati.cchtml.com/ (possibly even indirectly via a "trusted" mediator). They would gain a lot from detailed and focused bug reports, and for us there was a central place for documenting issues and known workarounds. But this requires that no one gets the feeling like throwing everyting into a "black hole of no return"

I'm not sure whether this "AMD/ATI public bug tracker"-thing was already "officially" discussed here before. But even if it was, AMD/ATIs attitude towards the community recently changed quite a bit, so perhaps it should be done now, anyway.

Michael, are you listening? Any ideas on how we could improve this situation?

[ambro814]

I've run glxgears and fgl_fglxgears, but I haven't noticed any memory leaks. I haven't done any extensive checks, but I've been running it for a few minutes and I haven't noticed any change in memory usage in ksysguard.
Thinkpad T60p, FireGL V5200

[Alistair]

I'm looking at whats happening on my system and I'm noting that the worst memory leak noted by valgrind is actually in libGL ... and apparently it occurs in both the libGL built by X and in libGL built by the ati install, but *only* when using the fglrx driver.

Overall at this moment I'm stumped as to where to go next. I've dumped my ati-drivers, and xorg installation and rebuilt from the ground up once already to see if I could eliminate the issue -- but it was NOT successful -- if anything I've ended up with a faster memory leak.

[yoshi314]

8.42 - "brown paperbag edition" (maybe we should buy some for fglrx devs - they're going to need them badly ;-) )

man, that's one hell of a leak. how did it get unnoticed?

[Alistair]

Now for the killer laugh of the week.

I ***have not touched my configurations one iota since the previous tests ........


What I DID do was power down the box and put my good old trusty 9550Pro 256M card back in the box, boot, start up , and run both glxgears and fgl_fglrxgears



Either there is *no* memory leak with this card, or the rate at which it leaks memory is ****substantially*** lower.....

[Svartalf]

8.42 - "brown paperbag edition" (maybe we should buy some for fglrx devs - they're going to need them badly ;-) )

man, that's one hell of a leak. how did it get unnoticed?

Because they don't Valgrind or Oprofile things and the QA people probably didn't test against the cards that seem to have the serious leak issue.