Hello All,
I am able to fix the 3M memory leak. 1M as explained already and the other
2M was because of my mistake -one extra thread that I had launched and was
not getting freed.
However, I still see few kBs ~132kB of memory leaked in every 2-3 iterations
of Init-Term Xserver. Note: In some
Hello All,
I need to fix memory leak issue urgently, any inputs regarding this would
very useful to me.
Thanks again.
On Wed, Oct 27, 2010 at 4:33 PM, vrushali shinde vrushali1...@gmail.comwrote:
Hello All,
I need to launch XServer in a thread and terminate(release resources and
kill thread
Hi,
On Mon, Nov 01, 2010 at 11:45:57AM +0530, ext vrushali shinde wrote:
Hello All,
I need to fix memory leak issue urgently, any inputs regarding this would
very useful to me.
Thanks again.
Kdrive development is practically dead. We just have some few people working
on Xephyr backend
internally calls FreeEventlist() which frees the 1M memory
allocated in InitEventList().
If anyone has any more idea of the memory leak in KDrive please let me know.
Thanks again,
Vrushali
On Mon, Nov 1, 2010 at 7:32 PM, Tiago Vignatti tiago.vigna...@nokia.comwrote:
Hi,
On Mon, Nov 01, 2010 at 11:45
Xserver, I
callGiveUp (0); function, that releases the XServer resources, then I
dlclose on Xserver library. However, when I start and terminate XServer in
above way, there seems to happen 3MB of memory leak in every cycle. After
narrowing down it is seen that following 2 function calls
Xserver, I
callGiveUp (0); function, that releases the XServer resources, then I
dlclose on Xserver library. However, when I start and terminate XServer in
above way, there seems to happen 3MB of memory leak in every cycle. After
narrowing down it is seen that following 2 function calls
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
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
:
refcount = glxPriv-refcount;
__glXUnrefDrawable(glxPriv);
if (refcount 1) {
glxPriv-pDraw = NULL;
glxPriv-drawId = 0;
}
Yep, that seems to work too... Magnus or Vasily can you guys confirm?
Memory leak problem seems resolved
;
__glXUnrefDrawable(glxPriv);
if (refcount 1) {
glxPriv-pDraw = NULL;
glxPriv-drawId = 0;
}
Yep, that seems to work too... Magnus or Vasily can you guys confirm?
Memory leak problem seems resolved, but I still see X crash
;
__glXUnrefDrawable(glxPriv);
if (refcount 1) {
glxPriv-pDraw = NULL;
glxPriv-drawId = 0;
}
Yep, that seems to work too... Magnus or Vasily can you guys confirm?
Memory leak problem seems resolved, but I still see X crash with:
(gdb) bt
#0
:
refcount = glxPriv-refcount;
__glXUnrefDrawable(glxPriv);
if (refcount 1) {
glxPriv-pDraw = NULL;
glxPriv-drawId = 0;
}
Yep, that seems to work too... Magnus or Vasily can you guys confirm?
Thanks,
Memory leak problem seems resolved, but I still see X
-refcount;
__glXUnrefDrawable(glxPriv);
if (refcount 1) {
glxPriv-pDraw = NULL;
glxPriv-drawId = 0;
}
Yep, that seems to work too... Magnus or Vasily can you guys confirm?
Thanks,
Memory leak problem seems resolved, but I still see X crash with:
(gdb
= NULL;
glxPriv-drawId = 0;
}
Yep, that seems to work too... Magnus or Vasily can you guys confirm?
Thanks,
Memory leak problem seems resolved, but I still see X crash with:
(gdb) bt
#0 0xb7fd5424 in __kernel_vsyscall ()
#1 0x03155660 in raise () from /lib/libc.so.6
#2
) {
glxPriv-pDraw = NULL;
glxPriv-drawId = 0;
}
Yep, that seems to work too... Magnus or Vasily can you guys confirm?
Thanks,
Memory leak problem seems resolved, but I still see X crash with:
(gdb) bt
#0 0xb7fd5424 in __kernel_vsyscall ()
#1 0x03155660 in raise () from
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
DM wrote:
Today I clicked in firefox 3.0.6 (fedora 10 / gnome / yum-updated / amd64 /
2GiB main memory / no swap) on
http://de.wikipedia.org/wiki/Datei:Www_Beo_cc.jpg
this URL:
http://upload.wikimedia.org/wikipedia/commons/f/ff/Www_Beo_cc.jpg
Download took quite long and the box'
Hi!
Today I clicked in firefox 3.0.6 (fedora 10 / gnome / yum-updated / amd64 /
2GiB main memory / no swap) on
http://de.wikipedia.org/wiki/Datei:Www_Beo_cc.jpg
this URL:
http://upload.wikimedia.org/wikipedia/commons/f/ff/Www_Beo_cc.jpg
Download took quite long and the box' responsiveness was
From: Colin Harrison colin.harri...@virgin.net
Free the memory allocated for ReturnData in FlushXEvents().
Copyright (C) Colin Harrison 2005-2008
http://www.straightrunning.com/XmingNotes/
http://sourceforge.net/projects/xming/
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
This memory leak has been fixed in server 1.5.
We reduced the problem to a simple X program.
It create two windows that overlap and
then calls XCopyArea on the lower window specifying an area
of the window that is covered by the upper window.
This leaks one region for every copy.
If anyone
I'm tracking down a memory leak in xorg server 1.3.
With some work loads we see a reproducible memory leak in the xorg server.
I have got as far as finding that miRegionCreate is being called 46000
times in 5m and
the memory it allocates is not being freed. There are 17000 blocks
leaked from
Barry Scott wrote:
In miregion.c xfreeData macro: Why do a test on the size?
Doesn't this lead to a leak of a malloc'ed block of memory?
#define xfreeData(reg) if ((reg)-data (reg)-data-size)
xfree((reg)-data)
No. If the size is 0, then reg-data is miEmptyData (or the pixman
equivalent in
I have found the leak.
At line 202 in miext/cw/cw_ops.c we have:
(*pBackingGC-ops-CopyArea)(pBackingSrc, pBackingDst,
pBackingGC, srcx, srcy, w, h,
dstx, dsty);
The RegionRec that is returned is lost.
Here is the stack trace of the allocation:
Breakpoint
2008/12/23 Barry Scott barry.sc...@onelan.co.uk:
I have found the leak.
isn't it simpler to update the xorg-server version?! 1.3 one is rather
old and probably
a memory leak bug would have been already discovered and fixed by now.
--
dott. ing. beso
On Fri, Oct 17, 2008 at 12:03:51AM +0200, Julien Cristau wrote:
On Thu, Oct 16, 2008 at 23:55:25 +0200, Julien Danjou wrote:
I think this belong here rather than on [EMAIL PROTECTED]
That was fixed a while ago, commits
2335eafe4b53c27f6f9ee1bab3e1f5842f896428 and
I think this belong here rather than on [EMAIL PROTECTED]
- Forwarded message from Aaron Plattner [EMAIL PROTECTED] -
From: Aaron Plattner [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Xcb] [PATCH] Fix memory leak in _XReply
Date: Wed, 17 Sep 2008 00:27:21 -0700
X-Spam-Status
On Thu, Oct 16, 2008 at 23:55:25 +0200, Julien Danjou wrote:
I think this belong here rather than on [EMAIL PROTECTED]
That was fixed a while ago, commits
2335eafe4b53c27f6f9ee1bab3e1f5842f896428 and
340422a5c7a413faef18666cada27cee14615250.
Cheers,
Julien
38 matches
Mail list logo
