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 Kimb
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,
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 Kostys
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 Heck
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 Kostys
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 (
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 a
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 a
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
lyx-d
> 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 compili
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 0
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
> /usr/lib/x86_64-linux-gnu/valgrind/vgp
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 possible.
>>
>I a
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 th
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
over
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 wi
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 wi
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 with comment
clarification). Richard?
JMarc
From 8e04248b
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 QCa
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 hand-m
Le 20/02/2017 à 18:25, Jean-Marc Lasgouttes a écrit :
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 c
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 hand-merging was correct, I hope I did not miss anything.
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
QCache>
and create the appropri
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 wrappers for insertion and retrieval.
Could
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 a go at this solution?
JMarc
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, t
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, tha
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 create
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 f
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.
L
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:
fantoma
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 TextClass::TextClas
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 v
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
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
LyX-2.0.2 on an Archlinux LyX distribution
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 Debian Squeeze and a si
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 a
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 Userguide, I find around 19ko/m
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
Ok. Give me some days to find the time to compile from the source and do the
tests.
On Wednesday, October 05, 2011 06:03:44 PM Tommaso Cucinotta wrote:
> Il 05/10/2011 22:54, Tommaso Cucinotta ha scritto:
> > 2) try to recompile LyX from the sources, to check whether the problem
> > still shows
Il 05/10/2011 22:54, Tommaso Cucinotta ha scritto:
2) try to recompile LyX from the sources, to check whether the problem
still shows up on your system or not in the current trunk. Shortly
(but it's going to take half an hour or so):
svn co svn://svn.lyx.org/lyx/lyx-devel/trunk lyx-trunk
cd
Il 05/10/2011 20:37, Rudi Gaelzer ha scritto:
All right, I installed valgrind and ran it as per instructions.
When it finally opened the text, the process massif-amd64-li... was
using 13.5%MEM and the demand was increasing very slowly without any
operation on the text.
When I opened the A
Le 04/10/2011 16:33, Tommaso Cucinotta a écrit :
I have some doubts about how UndoElement instances are handled.
a) they're pushed into the stack *by value*
std::deque c_;
so, more instances of UndoElement are created and copied wastefully:
void push(UndoElement const & v) {
Le 04/10/2011 16:33, Tommaso Cucinotta a écrit :
Thanks for looking at these. However, one of the biggest mess seems to
me the Undo related logic.
Let me report below my original question/doubts:
It look like I missed the original posting on this subject.
The questions look very interesting, I'
Il 04/10/2011 15:28, Jean-Marc Lasgouttes ha scritto:
Le 01/10/2011 02:04, Tommaso Cucinotta a écrit :
These are just cleanup ops that are not explicitly done on program exit,
but not a big deal, actually. They could help in having a better cleanup
of LyX at exit, but I'm not sure any of these d
Le 01/10/2011 02:04, Tommaso Cucinotta a écrit :
These are just cleanup ops that are not explicitly done on program exit,
but not a big deal, actually. They could help in having a better cleanup
of LyX at exit, but I'm not sure any of these deserves to be committed
(pls, comment).
I think such
Il 01/10/2011 19:01, Rudi Gaelzer ha scritto:
On Friday 30 September 2011 21:04:35 Tommaso Cucinotta wrote:
> For the increased memory usage notified by Rudi, if there were any
> problem with handling the Undo instances, then we should have seen
> something about Undo into the valgrind log. I
Il 30/09/2011 12:15, Jean-Marc Lasgouttes ha scritto:
What do we see?
1/ there is a continuous drift of memory use
2/ the most important part is the agregation of small allocations (not
very useful...)
3/ the second one is related to font loading by qt (remains stable)
4/ the third one is the
Le 30/09/2011 08:56, Tommaso Cucinotta a écrit :
Ok, please, find attached the obtained output parsed with ms_print.
Now, what do I do with this monster :-) ?
Where's the info about memory leaks ?
It is not necessarily a problem of memory leak (could be an ever-growing
cache, for example). Her
Le 29/09/11 01:13, Tommaso Cucinotta a écrit :
==26690== LEAK SUMMARY:
==26690== definitely lost: 12,126 bytes in 73 blocks
==26690== indirectly lost: 18,336 bytes in 571 blocks
==26690== possibly lost: 696,631 bytes in 2,590 blocks
==26690== still reachable: 898,279 bytes in 7,833 blocks
==26690
On Wednesday 28 September 2011 19:05:28 Tommaso Cucinotta wrote:
> Il 28/09/2011 20:40, Rudi Gaelzer ha scritto:
> > The document I'm working right now has thousands of formulas and I've
> > been using the advanced search pretty heavily. I can detect the
> > increasing memory load even with the ver
Il 29/09/2011 00:30, Jean-Marc Lasgouttes ha scritto:
Le 29/09/2011 00:05, Tommaso Cucinotta a écrit :
Also, I noticed a monotonic memory usage increase while editing the
document and especially creating math insets and deleting them later. I
guess this is due to the Undo feature, that keeps sto
Le 29/09/2011 00:05, Tommaso Cucinotta a écrit :
Also, I noticed a monotonic memory usage increase while editing the
document and especially creating math insets and deleting them later. I
guess this is due to the Undo feature, that keeps storing (a copy of)
all the insets even though you delete
Il 28/09/2011 20:40, Rudi Gaelzer ha scritto:
The document I'm working right now has thousands of formulas and I've
been using the advanced search pretty heavily. I can detect the
increasing memory load even with the very simple text that I attached
(memory.lyx). I was continually searching for
On Wednesday 28 September 2011 15:11:02 Tommaso Cucinotta wrote:
> Il 28/09/2011 16:36, Rudi Gaelzer ha scritto:
> > I don't know if this has already been reported. I made a quick scan
> > through both the user and devel lists and couldn't find anything related.
> >
> >
> > While editing a text
Il 28/09/2011 16:36, Rudi Gaelzer ha scritto:
I don't know if this has already been reported. I made a quick scan
through both the user and devel lists and couldn't find anything related.
While editing a text riddled with mathematical formulae, I had to use
advanced search several times to
On 04/30/2011 09:14 PM, venom00 wrote:
>> I've looked briefly at this one before, and I find it confusing. It
>> looks as if it is saying that we are leaking the docstring
>> word itself,
>> i.e., that it's not being cleaned up, but why would that be?
> Mmmh, I find it pretty simple: we have some
> I've looked briefly at this one before, and I find it confusing. It
> looks as if it is saying that we are leaking the docstring
> word itself,
> i.e., that it's not being cleaned up, but why would that be?
Mmmh, I find it pretty simple: we have some elements added to a set but never
removed.
On 04/30/2011 09:33 AM, venom00 wrote:
>> I'd like to hear your thoughts about these logs before trying
>> to get into them and understand what's wrong.
> The memory losses are sorted by size, so maybe we can try to fix at least the
> biggest memory leaks.
>
> For instance:
> ==22649== 47,920 byt
> I'd like to hear your thoughts about these logs before trying
> to get into them and understand what's wrong.
The memory losses are sorted by size, so maybe we can try to fix at least the
biggest memory leaks.
For instance:
==22649== 47,920 bytes in 960 blocks are indirectly lost in loss reco
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 sim
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 add
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
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
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 memory.
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
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
Abdelrazak Younes wrote:
> QPixmap are implicitly shared.
this was the missing brick.. thanks
pavel
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
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
cache,
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 u
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 t
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'
>> mean
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 remember
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
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 headac
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 t
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 sca
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 are
On Sun, Dec 09, 2007 at 01:25:35PM +0100, Peter Kümmel wrote:
>>> #define Q_PLUGIN_INSTANCE(IMPLEMENTATION) \
>>> { \
>>> static
>>> QT_PREPEND_NAMESPACE(QPointer) _instance;
>>> \
>>> if (!_instance) \
>>> _instance = new IMPLEMENTATION; \
>>>
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 jus
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 just opening and
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> On Mon, Nov 25, 2002 at 12:38:27PM +0100, Jean-Marc Lasgouttes
John> wrote:
>> I get them too, they are annoying.
John> make them dbg-only. They were useful when debuggingthe graphics
John> crashes of 1.2.0pre era, now they mainly serve
On Mon, 2002-11-25 at 22:08, Jean-Marc Lasgouttes wrote:
> > "Rod" == Rod Pinna <[EMAIL PROTECTED]> writes:
>
> Rod> Received unhandled X11 event Type: 13 Target: 0x1c0009e
> >> What action triggers them?
>
> Rod> Hmm, seems to be a preview latex fragment appearing on screen.
>
> I get them
On Mon, Nov 25, 2002 at 12:38:27PM +0100, Jean-Marc Lasgouttes wrote:
> I get them too, they are annoying.
make them dbg-only. They were useful when debuggingthe graphics crashes
of 1.2.0pre era, now they mainly serve as a reminder of how bad xforms
is ;)
regards
john
--
Khendon's Law: If the s
> "Rod" == Rod Pinna <[EMAIL PROTECTED]> writes:
Rod> Received unhandled X11 event Type: 13 Target: 0x1c0009e
>> What action triggers them?
Rod> Hmm, seems to be a preview latex fragment appearing on screen.
I get them too, they are annoying.
JMarc
> Rod> Received unhandled X11 event Type: 13 Target: 0x1c0009e
>
> What action triggers them?
Hmm, seems to be a preview latex fragment appearing on screen.
Rod
_
rod | "Beneath the waves, the waves / That's where I will be /
On 22 Nov 2002, Jean-Marc Lasgouttes wrote:
> > "Rod" == Rod Pinna <[EMAIL PROTECTED]> writes:
>
> Rod> Using 130cvs with xforms, after a few hours it was using 106M,
> Rod> and X was up to 80M. Rerunning get memory usage to 4M.
>
> What kind of documents do you edit? There may be some meory
> "Rod" == Rod Pinna <[EMAIL PROTECTED]> writes:
Rod> Using 130cvs with xforms, after a few hours it was using 106M,
Rod> and X was up to 80M. Rerunning get memory usage to 4M.
What kind of documents do you edit? There may be some meory leak
somewhere. 106M is not acceptable (unless your docu
Andre Poenitz wrote:
> What kernel?
2.4.10-4 (SuSE 7.3)
> I've seen this with any 2.4.x I tried and am now back to 2.2.19 which
> behaves nicely. No KDE, though.
I see. Thanks for the hint, I will probably downgrade too (or install 2.2.x
additionally again) if this keeps annoying me.
Juergen.
On Tue, Jun 04, 2002 at 11:14:40AM +0200, Juergen Spitzmueller wrote:
> But sometimes strange things are happening here: without doing anything, the
> whole box crawls down and the devices are busy for quite some time.
What kernel?
I've seen this with any 2.4.x I tried and am now back to 2.2.19
Lars Gullik Bjønnes wrote:
> [EMAIL PROTECTED] (Juergen Spitzmueller) writes:
> | For what it's worth, it compiles again :-)
>
> You were not running that much programs this time?
I don't think I did. I tried it several times and failed (I think I even
closed all apps one time).
But sometimes s
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> | A good first step would be to sort out why the configure
Lars> script does | not work with 2.52 on linux currently. I'd like to
Lars> have a common | version of autoconf/automake that works with
Lars> 1.2.x and 1.3.0cvs (it |
[EMAIL PROTECTED] (Juergen Spitzmueller) writes:
| For what it's worth, it compiles again :-)
You were not running that much programs this time?
--
Lgb
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | Andre Poenitz
| Lars> <[EMAIL PROTECTED]> writes:
>>>
| Lars> | | (but with automake 1.5 and not 1.6)
>>>
| Lars> | Have yo
For what it's worth, it compiles again :-)
Thanks,
Juergen.
Juergen Spitzmueller wrote:
> rty -lc -lm -L/usr/X11R6/lib -lX11
> /usr/i486-suse-linux/bin/ld: final link failed: Memory exhausted
> collect2: ld returned 1 exit status
> make[3]: *** [lyx] Error 1
> make[3]: Leaving directory `/home/j
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | Andre Poenitz
Lars> <[EMAIL PROTECTED]> writes:
>>
Lars> | | (but with automake 1.5 and not 1.6)
>>
Lars> | Have you also forgotten that we just came out of a code
Lars> freeze?
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> | Why not ... on the subject of controversial upgrades, I think
Lars> we should | drop all support for xforms pre-1.0 in 1.3
Lars> Agree. And when 1.3.0 is eventually released we will only
Lars> support the latest stable xform
On Mon, Jun 03, 2002 at 07:39:39PM +0100, John Levon wrote:
> Why not ... on the subject of controversial upgrades, I think we should
> drop all support for xforms pre-1.0 in 1.3
Is 1.0 out?
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they des
On Mon, Jun 03, 2002 at 07:20:12PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | (but with automake 1.5 and not 1.6)
>
> Have you also forgotten that we just came out of a code freeze?
Oh... so the freeze is over?
Haven't seen an announcement lately ;-}
A
1 - 100 of 138 matches
Mail list logo
