On Wed, Mar 25, 2009 at 10:21:51AM -0700, Jesse Barnes wrote:
In trying to track down the memory leak in 20704, I found that the DRI2
drawable destroy routine doesn't seem to get called when new drawables
are created and old ones destroyed (as in the glViewport case in the
bug).
Ok, sorry for
On Mon, 2009-04-06 at 14:57 -0700, Jesse Barnes wrote:
On Wed, 01 Apr 2009 17:46:08 +0200
Michel Dänzer mic...@daenzer.net wrote:
The real problem was pointed out by Pierre Willenbrock: If
glxPriv-pDraw is a pixmap, DrawableGone() destroys it, then later
DRI2DestroyDrawable dereferences
On Wed, 01 Apr 2009 17:46:08 +0200
Michel Dänzer mic...@daenzer.net wrote:
The real problem was pointed out by Pierre Willenbrock: If
glxPriv-pDraw is a pixmap, DrawableGone() destroys it, then later
DRI2DestroyDrawable dereferences it... The patch below seems to work
here - at least it hasn't
2009/4/1 Michel Dänzer mic...@daenzer.net:
On Mon, 2009-03-30 at 13:04 +0800, Shuang He wrote:
Shuang He wrote:
Jesse Barnes wrote:
On Fri, 27 Mar 2009 13:20:25 -0400
Kristian Høgsberg k...@bitplanet.net wrote:
The leak is (as you pointed out before) because we NULL the pDraw
On Mon, 2009-03-30 at 13:04 +0800, Shuang He wrote:
Shuang He wrote:
Jesse Barnes wrote:
On Fri, 27 Mar 2009 13:20:25 -0400
Kristian Høgsberg k...@bitplanet.net wrote:
The leak is (as you pointed out before) because we NULL the pDraw
pointer before calling the backend
Michel Dänzer wrote:
On Mon, 2009-03-30 at 13:04 +0800, Shuang He wrote:
Shuang He wrote:
Jesse Barnes wrote:
On Fri, 27 Mar 2009 13:20:25 -0400
Kristian Høgsberg k...@bitplanet.net wrote:
The leak is (as you pointed out before) because we NULL the pDraw
pointer
On Monday 30 March 2009, Shuang He wrote:
Jesse Barnes wrote:
On Fri, 27 Mar 2009 13:20:25 -0400
Kristian Høgsberg k...@bitplanet.net wrote:
On Thu, Mar 26, 2009 at 6:33 PM, Jesse Barnes
jbar...@virtuousgeek.org wrote:
Ok, I think this is where the leak was:
Magnus Kessler wrote:
On Monday 30 March 2009, Shuang He wrote:
Jesse Barnes wrote:
On Fri, 27 Mar 2009 13:20:25 -0400
Kristian Høgsberg k...@bitplanet.net wrote:
On Thu, Mar 26, 2009 at 6:33 PM, Jesse Barnes
jbar...@virtuousgeek.org wrote:
Ok, I think this is where
Jesse Barnes wrote:
On Fri, 27 Mar 2009 13:20:25 -0400
Kristian Høgsberg k...@bitplanet.net wrote:
On Thu, Mar 26, 2009 at 6:33 PM, Jesse Barnes
jbar...@virtuousgeek.org wrote:
Ok, I think this is where the leak was:
__glXUnrefDrawable-DrawableGone-__glXUnrefDrawable. This sequence
Shuang He wrote:
Jesse Barnes wrote:
On Fri, 27 Mar 2009 13:20:25 -0400
Kristian Høgsberg k...@bitplanet.net wrote:
On Thu, Mar 26, 2009 at 6:33 PM, Jesse Barnes
jbar...@virtuousgeek.org wrote:
Ok, I think this is where the leak was:
Jesse,
Thanks for the patch, I'm testing it now - it looks promising :)
X memory usage is more stable, but lsof | grep drm mm | wc -l still
increases - after 10 minutes it went up from 100 to 500... Is this
normal?
cheers,
Adam
2009/3/28 Jesse Barnes jbar...@virtuousgeek.org:
On Fri, 27
On Saturday 28 March 2009 02:42:53 Jesse Barnes wrote:
Yep, that seems to work too... Magnus or Vasily can you guys confirm?
I've just got xorg-server crash. Here's trace (not very usefull I think):
Backtrace:
0: /usr/bin/X(xorg_backtrace+0x3c) [0x813344c]
1: /usr/bin/X(xf86SigHandler+0x52)
On Saturday 28 Mar 2009 00:42:53 Jesse Barnes wrote:
Yep, that seems to work too... Magnus or Vasily can you guys confirm?
Seems to work fine for me, although I'm going to have an eye open for bugs that
might have previously been hidden in the now exposed code paths.
Is there any good
On Sat, 28 Mar 2009 11:35:20 +0100
Adam Lantos h...@playma.org wrote:
Jesse,
Thanks for the patch, I'm testing it now - it looks promising :)
X memory usage is more stable, but lsof | grep drm mm | wc -l still
increases - after 10 minutes it went up from 100 to 500... Is this
normal?
On Fri, 27 Mar 2009 13:20:25 -0400
Kristian Høgsberg k...@bitplanet.net wrote:
On Thu, Mar 26, 2009 at 6:33 PM, Jesse Barnes
jbar...@virtuousgeek.org wrote:
Ok, I think this is where the leak was:
__glXUnrefDrawable-DrawableGone-__glXUnrefDrawable. This sequence
meant the glxPriv would
On Fri, 27 Mar 2009 13:20:25 -0400
Kristian Høgsberg k...@bitplanet.net wrote:
On Thu, Mar 26, 2009 at 6:33 PM, Jesse Barnes
jbar...@virtuousgeek.org wrote:
Ok, I think this is where the leak was:
__glXUnrefDrawable-DrawableGone-__glXUnrefDrawable. This sequence
meant the glxPriv would
On Wednesday 25 March 2009, Jesse Barnes wrote:
In trying to track down the memory leak in 20704, I found that the DRI2
drawable destroy routine doesn't seem to get called when new drawables
are created and old ones destroyed (as in the glViewport case in the
bug).
The GLX core code takes
On Wednesday 25 March 2009 19:21:51 Jesse Barnes wrote:
Has anyone else seen this leak? Anyone care to educate me a bit more
about GLX drawable lifetime rules?
Yep, my system suffer from this leak too.
Thanks,
Jesse
diff --git a/glx/glxext.c b/glx/glxext.c
index c882372..73e5a9b 100644
On Thu, 26 Mar 2009 22:02:52 +0200
Vasily Khoruzhick anars...@gmail.com wrote:
On Wednesday 25 March 2009 19:21:51 Jesse Barnes wrote:
Has anyone else seen this leak? Anyone care to educate me a bit
more about GLX drawable lifetime rules?
Yep, my system suffer from this leak too.
Yeah
On Thu, 26 Mar 2009 14:20:07 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
What's weird is that __glXUnrefDrawable might be called by
DrawableGone (the top level X managed resource for glx drawables) due
to __glXUnrefDrawable calling FreeResourceByType, but then
DrawableGone will again
In trying to track down the memory leak in 20704, I found that the DRI2
drawable destroy routine doesn't seem to get called when new drawables
are created and old ones destroyed (as in the glViewport case in the
bug).
The GLX core code takes care of destroying drawables correctly though,
and even
21 matches
Mail list logo
