Re: Memory leak from list

On Sun, Feb 23, 2020 at 05:00:43PM -0500, Richard Kimberly Heck wrote: > On 2/23/20 4:11 PM, Scott Kostyshak wrote: > > On Sun, Feb 23, 2020 at 03:54:06PM -0500, Richard Kimberly Heck wrote: > >> On 2/23/20 2:31 PM, Scott Kostyshak wrote: > >>> On Sun, Feb 23, 2020 at 12:50:42PM -0500, Richard

Re: Memory leak from list

On 2/23/20 4:11 PM, Scott Kostyshak wrote: > On Sun, Feb 23, 2020 at 03:54:06PM -0500, Richard Kimberly Heck wrote: >> On 2/23/20 2:31 PM, Scott Kostyshak wrote: >>> On Sun, Feb 23, 2020 at 12:50:42PM -0500, Richard Kimberly Heck wrote: On 2/23/20 8:23 AM, Scott Kostyshak wrote: > On Tue,

Re: Memory leak from list

On Sun, Feb 23, 2020 at 03:54:06PM -0500, Richard Kimberly Heck wrote: > On 2/23/20 2:31 PM, Scott Kostyshak wrote: > > On Sun, Feb 23, 2020 at 12:50:42PM -0500, Richard Kimberly Heck wrote: > >> On 2/23/20 8:23 AM, Scott Kostyshak wrote: > >>> On Tue, Feb 18, 2020 at 08:28:33PM -0500, Scott

Re: Memory leak from list

On 2/23/20 2:31 PM, Scott Kostyshak wrote: > On Sun, Feb 23, 2020 at 12:50:42PM -0500, Richard Kimberly Heck wrote: >> On 2/23/20 8:23 AM, Scott Kostyshak wrote: >>> On Tue, Feb 18, 2020 at 08:28:33PM -0500, Scott Kostyshak wrote: On Tue, Feb 18, 2020 at 07:33:39PM -0500, Richard Kimberly

Re: Memory leak from list

On Sun, Feb 23, 2020 at 12:50:42PM -0500, Richard Kimberly Heck wrote: > On 2/23/20 8:23 AM, Scott Kostyshak wrote: > > On Tue, Feb 18, 2020 at 08:28:33PM -0500, Scott Kostyshak wrote: > >> On Tue, Feb 18, 2020 at 07:33:39PM -0500, Richard Kimberly Heck wrote: > >>> On 2/18/20 6:07 PM, Scott

Re: Memory leak from list

On 2/23/20 8:23 AM, Scott Kostyshak wrote: > On Tue, Feb 18, 2020 at 08:28:33PM -0500, Scott Kostyshak wrote: >> On Tue, Feb 18, 2020 at 07:33:39PM -0500, Richard Kimberly Heck wrote: >>> On 2/18/20 6:07 PM, Scott Kostyshak wrote: Valgrind gave me the following error: ==732== 112

Re: Memory leak from list

On Tue, Feb 18, 2020 at 08:28:33PM -0500, Scott Kostyshak wrote: > On Tue, Feb 18, 2020 at 07:33:39PM -0500, Richard Kimberly Heck wrote: > > On 2/18/20 6:07 PM, Scott Kostyshak wrote: > > > Valgrind gave me the following error: > > > > > > ==732== 112 (72 direct, 40 indirect) bytes in 1 blocks

Re: [RFC][PATCH] Fix for potential memory leak in GuiLyXFiles::updateContents

Am 20.02.2020 um 13:22 schrieb Enrico Forestieri : > > On Thu, Feb 20, 2020 at 09:37:12AM +0100, Stephan Witt wrote: >> Hi all, >> >> the last one of the potential memory leaks is a little bit trickier. >> >> The loop logic for subcatItem if cats contains catsave doesn’t guarantee >> a match so

Re: [RFC][PATCH] Fix for potential memory leak in GuiLyXFiles::updateContents

On Thu, Feb 20, 2020 at 09:37:12AM +0100, Stephan Witt wrote: > Hi all, > > the last one of the potential memory leaks is a little bit trickier. > > The loop logic for subcatItem if cats contains catsave doesn’t guarantee > a match so a check for the match is needed after all. > > This makes me

[RFC][PATCH] Fix for potential memory leak in GuiLyXFiles::updateContents

Hi all, the last one of the potential memory leaks is a little bit trickier. The loop logic for subcatItem if cats contains catsave doesn’t guarantee a match so a check for the match is needed after all. This makes me unsure what should be done in this case. Ignore it or warn about it or try

Re: Memory leak from list

On Wed, Feb 19, 2020 at 08:52:18AM +, Neven Sajko wrote: > > Well, actually the hardest part is waiting because LyX is very slow when > > run under valgrind. > > Try sanitizers instead. They are instrumentation that GCC or Clang can > include in executables. They do basically the same thing

Re: Memory leak from list

My instructions for the C compiler and linker command line were wrong: instead of -fsanitize=asan , use -fsanitize=address or -fsanitize=thread or -fsanitize=undefined or -fsanitize=memory . And, of course, include debugging symbols with "-g". Regards, Neven Sajko -- lyx-devel mailing list

Re: Memory leak from list

> Well, actually the hardest part is waiting because LyX is very slow when run > under valgrind. Try sanitizers instead. They are instrumentation that GCC or Clang can include in executables. They do basically the same thing as Valgrind, but should be much faster and since you are already

Re: Memory leak from list

On Tue, Feb 18, 2020 at 07:33:39PM -0500, Richard Kimberly Heck wrote: > On 2/18/20 6:07 PM, Scott Kostyshak wrote: > > Valgrind gave me the following error: > > > > ==732== 112 (72 direct, 40 indirect) bytes in 1 blocks are definitely > > lost in loss record 5,165 of 5,862 > > ==732==at

Re: Memory leak from list

On 2/18/20 6:07 PM, Scott Kostyshak wrote: > Valgrind gave me the following error: > > ==732== 112 (72 direct, 40 indirect) bytes in 1 blocks are definitely lost > in loss record 5,165 of 5,862 > ==732==at 0x483AE63: operator new(unsigned long) (in >

Memory leak from list

Valgrind gave me the following error: ==732== 112 (72 direct, 40 indirect) bytes in 1 blocks are definitely lost in loss record 5,165 of 5,862 ==732==at 0x483AE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==732==by

Re: Memory leak in master?

Hi Guillaume, I thought about it again, and you are right, of course. JMarc Le 24 février 2017 22:10:17 GMT+01:00, Guillaume Munch a écrit : >Le 22/02/2017 à 18:03, Jean-Marc Lasgouttes a écrit : >> It would be nice to hide these subtleties in the Cache >implementation, >> if

Re: Memory leak in master?

Le 22/02/2017 à 18:03, Jean-Marc Lasgouttes a écrit : Le 21/02/2017 à 20:13, Guillaume Munch a écrit : BTW, why don't you use Cache::contains in getLayout like you do for other cache uses? This is explained in the documentation of Cache::object. It is enough to check for a null pointer in

Re: Memory leak in master?

Le 23/02/2017 à 18:05, Richard Heck a écrit : Here is for reference the updated patch (even with comment clarification). Richard? OK. I'll test it over the next couple weeks, and if all is well move toward 2.2.3. rh Done at 998c3e7c8ef. There is no status.22x entry, since this is a fix

Re: Memory leak in master?

On 02/23/2017 04:46 AM, Jean-Marc Lasgouttes wrote: > Le 22/02/2017 à 18:03, Jean-Marc Lasgouttes a écrit : >> Indeed. Richard, I think this patch should go in 2.2.3, because the >> caching code that is in stable causes bad memory leaks with Qt5. > > Here is for reference the updated patch (even

Re: Memory leak in master?

On 02/23/2017 04:46 AM, Jean-Marc Lasgouttes wrote: > Le 22/02/2017 à 18:03, Jean-Marc Lasgouttes a écrit : >> Indeed. Richard, I think this patch should go in 2.2.3, because the >> caching code that is in stable causes bad memory leaks with Qt5. > > Here is for reference the updated patch (even

Re: Memory leak in master?

inters in the source. Fix memory leak when compiling with Qt5. As part as the backport to stable, this code has been change to work with C++98. (cherry picked from commit 33b696c8acf2e64b44d449180781de6dbc203709) (cherry picked from commit e04079aa528ecbf4a8e39ed2b19c3cb50174e151) (cherry picked from

Re: Memory leak in master?

Le 21/02/2017 à 20:13, Guillaume Munch a écrit : Thanks for doing this. I thought there was some bigger adaptation to the code to do but indeed it only looks like a matter of C++98 conversion. You mean it was a trap? It did not work %-p I think it's all good except: class Cache : private

Re: Memory leak in master?

Le 21/02/2017 à 07:19, Jean-Marc Lasgouttes a écrit : Le 21/02/2017 à 00:08, Guillaume Munch a écrit : Could you do the backport to stable? :) What about that? Please check especially the code related to LYX_USE_CXX11 in Cache.h. For the caching, I re-read the code to make sure that my

Re: Memory leak in master?

decreases at some point. It does not look similar to the slow creep of the memory leak. Again, I am not sure that I know how to interpret the results. Guillaume

Re: Memory leak in master?

Useful to cache copies of objects, including shared_ptrs. No risks of dangling pointer, and avoid naked pointers in the source. Fix memory leak when compiling with Qt5. As part as the backport to stable, this code has been change to work with C++98. (cherry picked from

Re: Memory leak in master?

Le 21/02/2017 à 00:08, Guillaume Munch a écrit : Le 20/02/2017 à 18:27, Jean-Marc Lasgouttes a écrit : Le 13/02/2017 à 20:55, Jean-Marc Lasgouttes a écrit : What I mean is that you can easily force QCache into shared ownership by replacing QCache with

Re: Memory leak in master?

Le 20/02/2017 à 18:27, Jean-Marc Lasgouttes a écrit : Le 13/02/2017 à 20:55, Jean-Marc Lasgouttes a écrit : What I mean is that you can easily force QCache into shared ownership by replacing QCache with QCache and create the appropriate

Re: Memory leak in master?

Le 13/02/2017 à 20:55, Jean-Marc Lasgouttes a écrit : What I mean is that you can easily force QCache into shared ownership by replacing QCache with QCache and create the appropriate wrappers for insertion and retrieval. Could you have

Re: Memory leak in master?

Le 10/02/2017 à 17:58, Guillaume Munch a écrit : There's more data, but I am not sure how to interpret the results that massif-visualizer shows. If you send the file or make it available, I can take a look. Here it is. But if it is like callgrind, it might lack the symbols. Interestingly,

Re: Memory leak with WordList

Le 31/12/2016 à 15:42, Guillaume Munch a écrit : Snippet of Valgrind output for stable below. The WordList object created in theWordList() never gets deleted, although QThreadStorage is supposed to be automagic. According to the docs, the GlobalWordLists were deleted with the QApplication,

Re: Memory leak with WordList

Le 31/12/2016 à 13:16, Jean-Marc Lasgouttes a écrit : WordList leaks all its contents on exit, which is very impolite (even though the memory will be reclaimed anyway). This hides real memory leaks that may happen elsewhere. Snippet of Valgrind output for stable below. The WordList object

Memory leak with WordList

WordList leaks all its contents on exit, which is very impolite (even though the memory will be reclaimed anyway). This hides real memory leaks that may happen elsewhere. Snippet of Valgrind output for stable below. The WordList object created in theWordList() never gets deleted, although

Re: Memory leak ?

Am 22.01.2012 um 21:58 schrieb Jean-Marc Lasgouttes: Le 22/01/12 02:09, Lars Gullik Bjønnes a écrit : My testing so far says the opposite. We are continually using more and more memory. Not especially fast, but it is there. A good tool to know where memory goes is the massif tool of

Re: Memory leak ?

Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit : | A good tool to know where memory goes is the massif tool of valgrind. This is the result from a ~6hrs run. I am not quite sure how to read it. Like what Stephan reported, we see: fantomas: ms_print massif.out.24204|grep

Re: Memory leak ?

On 01/23/2012 05:53 AM, Jean-Marc Lasgouttes wrote: Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit : | A good tool to know where memory goes is the massif tool of valgrind. This is the result from a ~6hrs run. I am not quite sure how to read it. Like what Stephan reported, we see:

Re: Memory leak ?

Op 23-1-2012 15:54, Richard Heck schreef: On 01/23/2012 05:53 AM, Jean-Marc Lasgouttes wrote: Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit : | A good tool to know where memory goes is the massif tool of valgrind. This is the result from a ~6hrs run. I am not quite sure how to read it.

Re: Memory leak ?

On 01/23/2012 12:04 PM, Vincent van Ravesteijn wrote: Op 23-1-2012 15:54, Richard Heck schreef: On 01/23/2012 05:53 AM, Jean-Marc Lasgouttes wrote: Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit : | A good tool to know where memory goes is the massif tool of valgrind. This is the result

Re: Memory leak ?

Am 22.01.2012 um 21:58 schrieb Jean-Marc Lasgouttes: > Le 22/01/12 02:09, Lars Gullik Bjønnes a écrit : >> My testing so far says the opposite. We are continually using more and >> more memory. Not especially fast, but it is there. > > A good tool to know where memory goes is the massif tool of

Re: Memory leak ?

Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit : | A good tool to know where memory goes is the massif tool of valgrind. This is the result from a ~6hrs run. I am not quite sure how to read it. Like what Stephan reported, we see: fantomas: ms_print massif.out.24204|grep

Re: Memory leak ?

On 01/23/2012 05:53 AM, Jean-Marc Lasgouttes wrote: Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit : | A good tool to know where memory goes is the massif tool of valgrind. This is the result from a ~6hrs run. I am not quite sure how to read it. Like what Stephan reported, we see:

Re: Memory leak ?

Op 23-1-2012 15:54, Richard Heck schreef: On 01/23/2012 05:53 AM, Jean-Marc Lasgouttes wrote: Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit : | A good tool to know where memory goes is the massif tool of valgrind. This is the result from a ~6hrs run. I am not quite sure how to read it.

Re: Memory leak ?

On 01/23/2012 12:04 PM, Vincent van Ravesteijn wrote: Op 23-1-2012 15:54, Richard Heck schreef: On 01/23/2012 05:53 AM, Jean-Marc Lasgouttes wrote: Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit : | A good tool to know where memory goes is the massif tool of valgrind. This is the result

Re: Memory leak ?

Richard Heck rgh...@comcast.net writes: | On 01/21/2012 08:09 PM, Lars Gullik Bjønnes wrote: Richard Heckrgh...@comcast.net writes: | On 01/21/2012 05:36 AM, Jean-Pierre Chrétien wrote: Hello, A French user tells me privately that he finds a big memeory leak in LyX-2.0.2 on an Archlinux

Re: Memory leak ?

Le 22/01/12 02:09, Lars Gullik Bjønnes a écrit : My testing so far says the opposite. We are continually using more and more memory. Not especially fast, but it is there. A good tool to know where memory goes is the massif tool of valgrind. JMarc

Re: Memory leak ?

Richard Heck writes: | On 01/21/2012 08:09 PM, Lars Gullik Bjønnes wrote: >> Richard Heck writes: >> >> | On 01/21/2012 05:36 AM, Jean-Pierre Chrétien wrote: Hello, A French user tells me privately that he finds a big memeory leak in

Re: Memory leak ?

Le 22/01/12 02:09, Lars Gullik Bjønnes a écrit : My testing so far says the opposite. We are continually using more and more memory. Not especially fast, but it is there. A good tool to know where memory goes is the massif tool of valgrind. JMarc

Memory leak ?

Hello, A French user tells me privately that he finds a big memeory leak in LyX-2.0.2 on an Archlinux LyX distribution (about 1.5Mo/mn). On my Debian Squeeze and a simple document, I find about 1.7ko/mn. Testing with the Userguide, I find around 19ko/mn with the following recipe: - open

Re: Memory leak ?

Jean-Pierre Chrétien jeanpierre.chretien at free.fr writes: I find no leak with Lyx-1.6.10, and an much smaller one (identical for each) of 0.28ko/mn with Lyx-2.0.2 and 2.0.1. I meant Lyx-2.0.0 and 2.0.1, sorry. -- Jean-Pierre

Re: Memory leak ?

Jean-Pierre Chrétien jeanpierre.chret...@free.fr writes: | Hello, | A French user tells me privately that he finds a big memeory leak in | LyX-2.0.2 on an Archlinux LyX distribution (about 1.5Mo/mn). | On my Debian Squeeze and a simple document, I find about 1.7ko/mn. | Testing with the

Re: Memory leak ?

On 01/21/2012 05:36 AM, Jean-Pierre Chrétien wrote: Hello, A French user tells me privately that he finds a big memeory leak in LyX-2.0.2 on an Archlinux LyX distribution (about 1.5Mo/mn). On my Debian Squeeze and a simple document, I find about 1.7ko/mn. Testing with the Userguide, I find

Re: Memory leak ?

On 01/21/2012 08:09 PM, Lars Gullik Bjønnes wrote: Richard Heckrgh...@comcast.net writes: | On 01/21/2012 05:36 AM, Jean-Pierre Chrétien wrote: Hello, A French user tells me privately that he finds a big memeory leak in LyX-2.0.2 on an Archlinux LyX distribution (about 1.5Mo/mn). On my

Memory leak ?

Hello, A French user tells me privately that he finds a big memeory leak in LyX-2.0.2 on an Archlinux LyX distribution (about 1.5Mo/mn). On my Debian Squeeze and a simple document, I find about 1.7ko/mn. Testing with the Userguide, I find around 19ko/mn with the following recipe: - open

Re: Memory leak ?

Jean-Pierre Chrétien free.fr> writes: > I find no leak with Lyx-1.6.10, and an much smaller one (identical for each) > of 0.28ko/mn with Lyx-2.0.2 and 2.0.1. I meant Lyx-2.0.0 and 2.0.1, sorry. -- Jean-Pierre

Re: Memory leak ?

Jean-Pierre Chrétien writes: | Hello, > | A French user tells me privately that he finds a big memeory leak in | LyX-2.0.2 on an Archlinux LyX distribution (about 1.5Mo/mn). > | On my Debian Squeeze and a simple document, I find about 1.7ko/mn. > | Testing with the

Re: Memory leak ?

On 01/21/2012 05:36 AM, Jean-Pierre Chrétien wrote: Hello, A French user tells me privately that he finds a big memeory leak in LyX-2.0.2 on an Archlinux LyX distribution (about 1.5Mo/mn). On my Debian Squeeze and a simple document, I find about 1.7ko/mn. Testing with the Userguide, I find

Re: Memory leak ?

On 01/21/2012 08:09 PM, Lars Gullik Bjønnes wrote: Richard Heck writes: | On 01/21/2012 05:36 AM, Jean-Pierre Chrétien wrote: Hello, A French user tells me privately that he finds a big memeory leak in LyX-2.0.2 on an Archlinux LyX distribution (about 1.5Mo/mn). On my

[PATCH] Fix Autosave Memory Leak

put this into 2.0.2. It looks pretty safe to me, and the memory leak, as I said, could be pretty bad otherwise. Richard From 1c0f114c36983d72af27ec0f26f643eb2e7845ba Mon Sep 17 00:00:00 2001 From: Richard Heck rgh...@lyx.org Date: Tue, 15 Nov 2011 11:08:50 -0500 Subject: [PATCH] Don't clone all

[PATCH] Fix Autosave Memory Leak

put this into 2.0.2. It looks pretty safe to me, and the memory leak, as I said, could be pretty bad otherwise. Richard >From 1c0f114c36983d72af27ec0f26f643eb2e7845ba Mon Sep 17 00:00:00 2001 From: Richard Heck <rgh...@lyx.org> Date: Tue, 15 Nov 2011 11:08:50 -0500 Subject: [PATCH] Do

Re: Memory leak?

rgheck wrote: On 08/10/2009 05:01 PM, Abdelrazak Younes wrote: On 10/08/2009 22:46, rgheck wrote: On 08/10/2009 04:21 PM, Abdelrazak Younes wrote: QPixmap are implicitly shared. So this means that when you do a = b, a will be a shadow copy of b up until it is modified, thus occupying zero

Re: Memory leak?

On 08/11/2009 03:40 AM, Abdelrazak Younes wrote: So, if setPixmap() returns true, then can't we do something like reset() the cached_item_ and just get rid if that QImage? You can try. Last time I did, I failed. But I was so upset about this piece of code that maybe the solution was much

Re: Memory leak?

rgheck wrote: On 08/10/2009 05:01 PM, Abdelrazak Younes wrote: On 10/08/2009 22:46, rgheck wrote: On 08/10/2009 04:21 PM, Abdelrazak Younes wrote: QPixmap are implicitly shared. So this means that when you do a = b, a will be a shadow copy of b up until it is modified, thus occupying zero

Re: Memory leak?

On 08/11/2009 03:40 AM, Abdelrazak Younes wrote: So, if setPixmap() returns true, then can't we do something like reset() the cached_item_ and just get rid if that QImage? You can try. Last time I did, I failed. But I was so upset about this piece of code that maybe the solution was much

Memory leak?

hi, for the third time my system get frozen because of bug http://www.lyx.org/trac/ticket/5002. it seems when we load eg. jpg image to cache and rescale it, the original image is not forgoten so even small scale is of no help and more print-ready image are able to knock system down. the code

Re: Memory leak?

On 10/08/2009 21:34, Pavel Sanda wrote: hi, for the third time my system get frozen because of bug http://www.lyx.org/trac/ticket/5002. it seems when we load eg. jpg image to cache and rescale it, the original image is not forgoten so even small scale is of no help and more print-ready image

Re: Memory leak?

On 10/08/2009 21:39, Abdelrazak Younes wrote: On 10/08/2009 21:34, Pavel Sanda wrote: hi, for the third time my system get frozen because of bug http://www.lyx.org/trac/ticket/5002. it seems when we load eg. jpg image to cache and rescale it, the original image is not forgoten so even small

Re: Memory leak?

Abdelrazak Younes wrote: Very intricate! The problem is not coming from Qt but from our own caching mechanism which is heavy and is redundant with Qt own caching system. Last time I tried to clean up this mess I stopped at this issue with a big headache... The only sane solution is to get

Re: Memory leak?

On 10/08/2009 21:46, Pavel Sanda wrote: Abdelrazak Younes wrote: Very intricate! The problem is not coming from Qt but from our own caching mechanism which is heavy and is redundant with Qt own caching system. Last time I tried to clean up this mess I stopped at this issue with a big

Re: Memory leak?

Abdelrazak Younes wrote: but my question is simpler now: why should original_ = QImage(); release the memory as the comment above says? if not what would be correct way of releasing it? This code works and is not the problem. I don't remember the details but the original image is

Re: Memory leak?

On 10/08/2009 21:55, Pavel Sanda wrote: Abdelrazak Younes wrote: but my question is simpler now: why should original_ = QImage(); release the memory as the comment above says? if not what would be correct way of releasing it? This code works and is not the problem. I don't

Re: Memory leak?

Abdelrazak Younes wrote: This code works and is not the problem. I don't remember the details but the original image is also stored somewhere else in the graphics cache, AFAIR. which doesn't help me to understand what '// Clear the pixmap to save some memory' means :) It

Re: Memory leak?

On 10/08/2009 22:11, Pavel Sanda wrote: Abdelrazak Younes wrote: This code works and is not the problem. I don't remember the details but the original image is also stored somewhere else in the graphics cache, AFAIR. which doesn't help me to understand what '// Clear the pixmap

Re: Memory leak?

On 08/10/2009 04:16 PM, Abdelrazak Younes wrote: On 10/08/2009 22:11, Pavel Sanda wrote: Abdelrazak Younes wrote: This code works and is not the problem. I don't remember the details but the original image is also stored somewhere else in the graphics cache, AFAIR. which doesn't help me to

Re: Memory leak?

On 10/08/2009 22:18, rgheck wrote: On 08/10/2009 04:16 PM, Abdelrazak Younes wrote: On 10/08/2009 22:11, Pavel Sanda wrote: Abdelrazak Younes wrote: This code works and is not the problem. I don't remember the details but the original image is also stored somewhere else in the graphics

Re: Memory leak?

On Mon, Aug 10, 2009 at 09:34:00PM +0200, Pavel Sanda wrote: hi, for the third time my system get frozen because of bug http://www.lyx.org/trac/ticket/5002. it seems when we load eg. jpg image to cache and rescale it, the original image is not forgoten so even small scale is of no help and

Re: Memory leak?

Abdelrazak Younes wrote: QPixmap are implicitly shared. this was the missing brick.. thanks pavel

Re: Memory leak?

On 08/10/2009 04:21 PM, Abdelrazak Younes wrote: QPixmap are implicitly shared. So this means that when you do a = b, a will be a shadow copy of b up until it is modified, thus occupying zero additional memory. This is the same concept as shared pointer, the object, and thus the memory, is not

Re: Memory leak?

On 10/08/2009 22:46, rgheck wrote: On 08/10/2009 04:21 PM, Abdelrazak Younes wrote: QPixmap are implicitly shared. So this means that when you do a = b, a will be a shadow copy of b up until it is modified, thus occupying zero additional memory. This is the same concept as shared pointer, the

Re: Memory leak?

On 08/10/2009 05:01 PM, Abdelrazak Younes wrote: On 10/08/2009 22:46, rgheck wrote: On 08/10/2009 04:21 PM, Abdelrazak Younes wrote: QPixmap are implicitly shared. So this means that when you do a = b, a will be a shadow copy of b up until it is modified, thus occupying zero additional

Re: Memory leak?

Richard Heck wrote: My thought was more simpleminded, but I don't know this code. Why do we need a cache of the original image once the pixmap has been set? If the original is changed, then presumably we want to reload. But if it doesn't change, we don't need access to it any more, do we?

Re: Memory leak?

On 08/10/2009 06:23 PM, Pavel Sanda wrote: Richard Heck wrote: My thought was more simpleminded, but I don't know this code. Why do we need a cache of the original image once the pixmap has been set? If the original is changed, then presumably we want to reload. But if it doesn't change, we

Memory leak?

hi, for the third time my system get frozen because of bug http://www.lyx.org/trac/ticket/5002. it seems when we load eg. jpg image to cache and rescale it, the original image is not forgoten so even small scale is of no help and more print-ready image are able to knock system down. the code

Re: Memory leak?

On 10/08/2009 21:34, Pavel Sanda wrote: hi, for the third time my system get frozen because of bug http://www.lyx.org/trac/ticket/5002. it seems when we load eg. jpg image to cache and rescale it, the original image is not forgoten so even small scale is of no help and more print-ready image

Re: Memory leak?

On 10/08/2009 21:39, Abdelrazak Younes wrote: On 10/08/2009 21:34, Pavel Sanda wrote: hi, for the third time my system get frozen because of bug http://www.lyx.org/trac/ticket/5002. it seems when we load eg. jpg image to cache and rescale it, the original image is not forgoten so even small

Re: Memory leak?

Abdelrazak Younes wrote: > Very intricate! > > The problem is not coming from Qt but from our own caching mechanism which > is heavy and is redundant with Qt own caching system. Last time I tried to > clean up this mess I stopped at this issue with a big headache... The only > sane solution is

Re: Memory leak?

On 10/08/2009 21:46, Pavel Sanda wrote: Abdelrazak Younes wrote: Very intricate! The problem is not coming from Qt but from our own caching mechanism which is heavy and is redundant with Qt own caching system. Last time I tried to clean up this mess I stopped at this issue with a big

Re: Memory leak?

Abdelrazak Younes wrote: >> but my question is simpler now: >> why should original_ = QImage(); release the memory as the comment above >> says? >> if not what would be correct way of releasing it? >> > > This code works and is not the problem. I don't remember the details but > the original

Re: Memory leak?

On 10/08/2009 21:55, Pavel Sanda wrote: Abdelrazak Younes wrote: but my question is simpler now: why should original_ = QImage(); release the memory as the comment above says? if not what would be correct way of releasing it? This code works and is not the problem. I don't

Re: Memory leak?

Abdelrazak Younes wrote: >>> This code works and is not the problem. I don't remember the details but >>> the original image is also stored somewhere else in the graphics cache, >>> AFAIR. >>> >> >> which doesn't help me to understand what '// Clear the pixmap to save some >> memory' >>

Re: Memory leak?

On 10/08/2009 22:11, Pavel Sanda wrote: Abdelrazak Younes wrote: This code works and is not the problem. I don't remember the details but the original image is also stored somewhere else in the graphics cache, AFAIR. which doesn't help me to understand what '// Clear the pixmap

Re: Memory leak?

On 08/10/2009 04:16 PM, Abdelrazak Younes wrote: On 10/08/2009 22:11, Pavel Sanda wrote: Abdelrazak Younes wrote: This code works and is not the problem. I don't remember the details but the original image is also stored somewhere else in the graphics cache, AFAIR. which doesn't help me to

Re: Memory leak?

On 10/08/2009 22:18, rgheck wrote: On 08/10/2009 04:16 PM, Abdelrazak Younes wrote: On 10/08/2009 22:11, Pavel Sanda wrote: Abdelrazak Younes wrote: This code works and is not the problem. I don't remember the details but the original image is also stored somewhere else in the graphics

Re: Memory leak?

On Mon, Aug 10, 2009 at 09:34:00PM +0200, Pavel Sanda wrote: > hi, > for the third time my system get frozen because of > bug http://www.lyx.org/trac/ticket/5002. > > it seems when we load eg. jpg image to cache and rescale it, the > original image is not forgoten so even small scale is of no

Re: Memory leak?

Abdelrazak Younes wrote: > QPixmap are implicitly shared. this was the missing brick.. thanks pavel

Re: Memory leak?

On 08/10/2009 04:21 PM, Abdelrazak Younes wrote: QPixmap are implicitly shared. So this means that when you do a = b, a will be a shadow copy of b up until it is modified, thus occupying zero additional memory. This is the same concept as shared pointer, the object, and thus the memory, is not

Re: Memory leak?

On 10/08/2009 22:46, rgheck wrote: On 08/10/2009 04:21 PM, Abdelrazak Younes wrote: QPixmap are implicitly shared. So this means that when you do a = b, a will be a shadow copy of b up until it is modified, thus occupying zero additional memory. This is the same concept as shared pointer, the

Re: Memory leak?

On 08/10/2009 05:01 PM, Abdelrazak Younes wrote: On 10/08/2009 22:46, rgheck wrote: On 08/10/2009 04:21 PM, Abdelrazak Younes wrote: QPixmap are implicitly shared. So this means that when you do a = b, a will be a shadow copy of b up until it is modified, thus occupying zero additional

Re: Memory leak?

Richard Heck wrote: > My thought was more simpleminded, but I don't know this code. Why do we > need a cache of the original image once the pixmap has been set? If the > original is changed, then presumably we want to reload. But if it doesn't > change, we don't need access to it any more, do

Re: Memory leak?

On 08/10/2009 06:23 PM, Pavel Sanda wrote: Richard Heck wrote: My thought was more simpleminded, but I don't know this code. Why do we need a cache of the original image once the pixmap has been set? If the original is changed, then presumably we want to reload. But if it doesn't change, we

Re: memory leak in Qt?

Andre Poenitz wrote: On Mon, Dec 03, 2007 at 11:00:00PM +0100, Peter Kümmel wrote: Playing around with vld I came to the conclusion that there is a memory leak in Qt's plugin system. When I trace the allocations of Qt (see ForceIncludeModules in the vld.ini file) I get attached output after

  1   2   3   >