On Fri, Jun 21, 2024 at 05:24:16PM GMT, Jean-Marc Lasgouttes wrote:
> Le 20/06/2024 à 20:03, Scott Kostyshak a écrit :
> > This report is from opening LyX, starting a new document, and quitting.
> > How can I read it to know if it's LyX's fault or not? Specifically, how
> > can I know whether the u
On Fri, Jun 21, 2024 at 04:16:32PM GMT, Pavel Sanda wrote:
> On Thu, Jun 20, 2024 at 02:00:08PM -0400, Scott Kostyshak wrote:
> > When I export the English Welcome.lyx on the command line with the
> > following command:
> >
> > lyx -e default Welcome.lyx
> >
> > I get the following output:
> >
Le 20/06/2024 à 20:03, Scott Kostyshak a écrit :
This report is from opening LyX, starting a new document, and quitting.
How can I read it to know if it's LyX's fault or not? Specifically, how
can I know whether the uninitialised value is created inside
QPainter::drawPixmap() or if it's instead i
On Thu, Jun 20, 2024 at 02:00:08PM -0400, Scott Kostyshak wrote:
> When I export the English Welcome.lyx on the command line with the following
> command:
>
> lyx -e default Welcome.lyx
>
> I get the following output:
>
> ==8181== Syscall param waitid(infop) points to unaddressable byte(s)
>
This report is from opening LyX, starting a new document, and quitting.
How can I read it to know if it's LyX's fault or not? Specifically, how
can I know whether the uninitialised value is created inside
QPainter::drawPixmap() or if it's instead in
lyx::frontend::(anonymous namespace)::BackgroundW
When I export the English Welcome.lyx on the command line with the following
command:
lyx -e default Welcome.lyx
I get the following output:
==8181== Syscall param waitid(infop) points to unaddressable byte(s)
==8181==at 0x628925D: syscall (syscall.S:38)
==8181==by 0x5B9A7A6: ??? (in
Attached is part of a Valgrind log (the full log is 1MB, let me know if
you want to go leak hunting). I was trying to investigate
https://www.lyx.org/trac/ticket/12510. I get the Valgrind message when
opening probability8.lyx on that ticket.
Also attached is a possible patch that fixes this
On Thu, Jan 01, 1970 at 12:00:00AM +, Kornel Benko wrote:
> commit 353295e4997e5719b1189d119b9745031bc45af4
> Author: Kornel Benko
> Date: Tue Apr 7 12:12:29 2020 +0200
>
> Cmake tests: Start preparing for tests involving valgrind
> ---
Thanks! I look forward to te
ping to investigate
> >>>>>> this memory leak but it seems to be beyond my knowledge.
> >>>>> Do you have recipy to reproduce valgrind's warning?
> >>>> 1. I run the following command (you will need to adapt it):
> >>>>
> >>
>> Do you have recipy to reproduce valgrind's warning?
>>>> 1. I run the following command (you will need to adapt it):
>>>>
>>>> valgrind --leak-check=full --track-origins=yes --log-file=valgrind.log
>>>> ~/lyxbuilds/master/CMakeBuil
x27;s warning?
> >> 1. I run the following command (you will need to adapt it):
> >>
> >> valgrind --leak-check=full --track-origins=yes --log-file=valgrind.log
> >> ~/lyxbuilds/master/CMakeBuild/bin/lyx -userdir ~/lyxbuilds/master/user-dir
> >>
> >> 2. Do &q
or taking a look. I was hoping to investigate
>>>> this memory leak but it seems to be beyond my knowledge.
>>> Do you have recipy to reproduce valgrind's warning?
>> 1. I run the following command (you will need to adapt it):
>>
>> valgrind --leak-che
; > this memory leak but it seems to be beyond my knowledge.
> >
> > Do you have recipy to reproduce valgrind's warning?
>
> 1. I run the following command (you will need to adapt it):
>
> valgrind --leak-check=full --track-origins=yes --log-file=valgri
e recipy to reproduce valgrind's warning?
1. I run the following command (you will need to adapt it):
valgrind --leak-check=full --track-origins=yes --log-file=valgrind.log
~/lyxbuilds/master/CMakeBuild/bin/lyx -userdir ~/lyxbuilds/master/user-dir
2. Do "ctrl + n" to start a ne
On Sat, Feb 15, 2020 at 09:42:52PM +0100, Pavel Sanda wrote:
> On Fri, Feb 14, 2020 at 08:09:09PM -0500, Scott Kostyshak wrote:
> > Thanks to both of you for taking a look. I was hoping to investigate
> > this memory leak but it seems to be beyond my knowledge.
>
> Do you have recipy to reproduce
On Fri, Feb 14, 2020 at 08:09:09PM -0500, Scott Kostyshak wrote:
> Thanks to both of you for taking a look. I was hoping to investigate
> this memory leak but it seems to be beyond my knowledge.
Do you have recipy to reproduce valgrind's warning?
Pavel
--
lyx-devel mailing list
lyx-devel@lists.l
ete on these
> pointers, but the whole point of this change (see 6ad1b1cd0) was not to
> recreate all the objects every time we reset the TocModel. I.e., the
> pointers don't change. We just clear the objects to which they point and
> then reuse them.
>
> I'm puzzled. Is
b/dev/src/corelib/tools/qhash.h
I doubt that it is QHash's responsibility to call delete on these
pointers, but the whole point of this change (see 6ad1b1cd0) was not to
recreate all the objects every time we reset the TocModel. I.e., the
pointers don't change. We just clear the objects to
On Thu, Feb 13, 2020 at 09:58:15PM -0500, Scott Kostyshak wrote:
> The corresponding line of TocModel.cpp:362 is the line with "new" below:
>
> // First, fill in the toc models.
> iterator mod_it = models_.find(type);
> if (mod_it == models_.end())
> mod_it = models_.insert(type, new T
Valgrind gave me the following when I was trying to debug what I believe
to be a separate issue:
==20945== 840 (336 direct, 504 indirect) bytes in 7 blocks are definitely
lost in loss record 5,624 of 5,867
==20945==at 0x483AE63: operator new(unsigned long) (in
/usr/lib/x86_64-linux
On Thu, Sep 29, 2016 at 07:12:40PM -0700, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > How did you know it was preview_error_? I'm searching for bug-fixing
> > intuition.
>
> valgrind log -> LaTeX.cpp:115 -> clean_start -> buffer.lastPreviewError()
> [Con
Scott Kostyshak wrote:
> How did you know it was preview_error_? I'm searching for bug-fixing
> intuition.
valgrind log -> LaTeX.cpp:115 -> clean_start -> buffer.lastPreviewError()
[Converter.cpp:656] ->
d->preview_error_ [Buffer.cpp:1200] -> preview_error
k these out.
> fixing preview_error_ should fix your valgrind err.
How did you know it was preview_error_? I'm searching for bug-fixing
intuition.
Also, do you know why Valgrind did not simply say something like
"preview_error_ was used before initialized" ? (I do use
--track-orig
_file_
preview_format_
preview_error_
tracked_changes_present_
but you might want to carefully check all members.
fixing preview_error_ should fix your valgrind err.
these uninitialized guys get transfered in constructor of LaTeX class.
pavel
I am trying to investigate what I think is a bug where sometimes when I
compile sk/Intro.lyx with system fonts + LuaTeX it gives an error and
sometimes not.
I wouldn't be surprised if the Valgrind error I see has nothing to do
with it, but nonetheless it seems important. I get the following
On 11/18/2014 01:21 PM, Georg Baum wrote:
Georg Baum wrote:
commit e5845fea49e6c8a2cae0dfd8c708a31ae3d67719
Author: Georg Baum
Date: Mon Nov 17 22:08:21 2014 +0100
Fix memory error detected by valgrind
The assignment name = sub.str(1) reads from the first argument given
Georg Baum wrote:
> commit e5845fea49e6c8a2cae0dfd8c708a31ae3d67719
> Author: Georg Baum
> Date: Mon Nov 17 22:08:21 2014 +0100
>
> Fix memory error detected by valgrind
>
> The assignment name = sub.str(1) reads from the first argument given
>
On a Linux box:
valgrind --leak-check=full src/lyx
Open up the Users' Guide using the menu "Help>Users' Guide"
Wait some time...
Close LyX with "File>Exit"
That produces the rather disturbing report. This is with a bang-up-to-date
check out.
--
Angus
valgrin
>>>>> "Dov" == Dov Feldstern <[EMAIL PROTECTED]> writes:
Dov> Hi! The behavior Darren was describing got me thinking of
Dov> valgrind. Is anyone regularly (or occasionally) testing LyX using
Dov> valgrind?
I do that from time to time. And it did find bugs for us.
JMarc
Hi!
The behavior Darren was describing got me thinking of valgrind. Is
anyone regularly (or occasionally) testing LyX using valgrind? (If
anyone's not familiar with valgrind: it's an open source runtime memory
checker which does a lot more than just memory checking, for example, I
Without this patch valgrind complains about an uninitialized variable
at startup. Since it is kind of obvious, I'll just commit (note that
it does also a tiny bit of reformatting)
JMarc
Index: src/frontends/Applicat
Angus Leeming wrote:
Is QPreambleDialogBase.ui old cruft that should be removed???
Yes.
Ok, I will move it to the attic tomorrow.
Michael
Michael Schmitt wrote:
> enclosed please find some new (?) bug reports.
> Is QPreambleDialogBase.ui old cruft that should be removed???
Yes.
--
Angus
with right mouse button
=> First valgrind message, then crash
==3279== Conditional jump or move depends on uninitialised value(s)
==3279==at 0x80CE4FF: operator==(Change const&, Change const&)
(changes.C:28)
==3279==by 0x80D0484: Changes::lyxMarkChange(std::ostream&, int&
> The last interesting thingy is the dark blue 'stack' entry. This
> memory grows when I press PageDown continuously and goes down when LyX
> has managed to keep up with the number of PageDown request I have
> issued. So there seems to be some recusrsivity going on when LyX
> cannot execute events
Jean-Marc Lasgouttes wrote:
>> "Angus" == Angus Leeming <[EMAIL PROTECTED]>
>> writes:
>
> Angus> Jean-Marc Lasgouttes wrote:
>>> The light blue entry is interesting, since it seems to point to
>>> the banner. Following the stack leads to:
>>> http://www-rocq.inria.fr/~lasgoutt/lyx/massif
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Jean-Marc Lasgouttes wrote:
>> The light blue entry is interesting, since it seems to point to the
>> banner. Following the stack leads to:
>> http://www-rocq.inria.fr/~lasgoutt/lyx/massif.10779.html#bB24C7D08
>> therefore hinting a
Jean-Marc Lasgouttes wrote:
> The light blue entry is interesting, since it seems to point to the
> banner. Following the stack leads to:
> http://www-rocq.inria.fr/~lasgoutt/lyx/massif.10779.html#bB24C7D08
> therefore hinting at the graphics cache. Since the is no graphics in
> Customization.lyx
I took a look at what happens when running lyx under the heap profiler
massif. The command used is
valgrind --tool=massif --format=html --depth=10 ./lyx
~/src/lyx/lyx-devel/lib/doc/Customization.lyx
and then I pressed pagedown repetedly until the scrollbar was at the
middle of the document
but I get basically the same + 2
Georg> strncpy errors with lyx cvs and xforms-1.0-218 on SuSE 9.0
Georg> (german locale). This was with valgrind 2.0.0, but 2.1.1 does
Georg> not show any difference.
This strncpy error is harmless, but fixed in xforms cvs.
JMarc
is was with
valgrind 2.0.0, but 2.1.1 does not show any difference.
Georg
==14833== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==14833== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==14833== Using valgrind-2.0.0, a program supervision framework for x86-linux.
==1
Firing up the XForms version of lyx under valgrind and then
shutting down immediately produces the following error report.
It would be nice if we could clean this up, but I can't see
anything wrong with the LyX or XForms code, which suggests bugs
in the X11 routines.
No doubt I'v
Andre Poenitz wrote:
> I don't mean the find scheme, but the 'dialog' scheme. To search for a
> 'real' formula one must be able to enter it in the search dialog. Which,
> in turn, means that the search dialog needs to accept almost arbitrary
> data instead of a simple string. Sort of 'embedded Ins
Andre Poenitz wrote:
> I don't mean the find scheme, but the 'dialog' scheme. To search for
> a 'real' formula one must be able to enter it in the search dialog.
> Which, in turn, means that the search dialog needs to accept almost
> arbitrary data instead of a simple string. Sort of 'embedded
> In
On Wed, Jan 07, 2004 at 01:53:29PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > On Wed, Jan 07, 2004 at 01:30:02PM +0100, Alfredo Braunstein wrote:
> > Would be a good starting point. Searching for real formulas would be
> > better, of course, but that would involve something simi
Andre Poenitz wrote:
> On Wed, Jan 07, 2004 at 01:30:02PM +0100, Alfredo Braunstein wrote:
> Would be a good starting point. Searching for real formulas would be
> better, of course, but that would involve something similar to a
> InsetText as 'search' field in the S&R dialog. I am not sure whethe
On Wed, Jan 07, 2004 at 01:30:02PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > On Wed, Jan 07, 2004 at 01:00:53PM +0100, Andre' Poenitz wrote:
> >> But should be re-added somehow...
> >
> > Incidently, where do I start?
>
> It depends on what we want.
I want real S&R in math.
Andre Poenitz wrote:
> On Wed, Jan 07, 2004 at 01:00:53PM +0100, Andre' Poenitz wrote:
>> But should be re-added somehow...
>
> Incidently, where do I start?
It depends on what we want.
> lyx::find seems to use insets only implicitly by using PosIterator,
> i.e. does not descend into math at a
On Wed, Jan 07, 2004 at 01:00:53PM +0100, Andre' Poenitz wrote:
> But should be re-added somehow...
Incidently, where do I start?
lyx::find seems to use insets only implicitly by using PosIterator,
i.e. does not descend into math at all.
Andre'
--
Those who desire to give up Freedom in order
Hello everybody,
a new release of our favourite debugging tool is available:
http://valgrind.kde.org/downloads.html
Michael
Hi,
I cannot reproduce this problem (I was moving the cursor innocently
through nested descriptions in read-only file TOC.lyx) but nevertheless
you might consider it interesting.
==18947== Conditional jump or move depends on uninitialised value(s)
==18947==at 0x816C72E: LyXText::setCursor(L
Any idea why this happened?
All I remember is that I cut some text and put it at the end of the
document. When I wanted to move the cursor upwards (which IIRC was at
the final empty line), the following crash occurred. Obviously, layout()
returns an invalid pointer (0x1C). Unfortunately, I cann
LyXLex &)
>> (../../../lyx-devel/src/mathed/formulamacro.C:113)
Andre> I just swapped two lines. Could you check whether this fixed
Andre> the problem?
No I can't, because I can run valgrind only at home. But you can do it
yourself :) Anyway, your fix seems reasonable.
JMarc
On Thu, Jul 25, 2002 at 09:48:57AM +0200, Jean-Marc Lasgouttes wrote:
> This one may be bogus:
>
> ==2426== Conditional jump or move depends on uninitialised value(s)
> ==2426==at 0x404873D5: (within /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so)
> ==2426==by 0x8195004: initMath(void)
> (../.
If I load the UserGuide, then quit, valgrind has among
other things these complaints in mathed:
This one may be bogus:
==2426== Conditional jump or move depends on uninitialised value(s)
==2426==at 0x404873D5: (within /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so)
==2426==by 0x8195004
Hi,
Julian Seward, the author of valgrind, is a wizard!
Yesterday, he has implemented the facility to invoke gdb when a memory
access error occurs. After leaving gdb, valgrind takes over control
again and program execution proceeds as if nothing has ever happened!
If I hadn't tested
On Tue, Feb 19, 2002 at 02:15:49PM -0800, Kayvan A. Sylvan wrote:
> Where is valgrind to be found again?
go to lists.kde.org and search for valgrind on kde-core-devel
regards
john
--
"They eat cold meat for breakfast and make jokes about gzip."
- Rik Hemsley on KDE developers
ave never heard
> of "valgrind" before.
>
> Thanks for the hint, John.
>
> Michael
Where is valgrind to be found again?
--
Kayvan A. Sylvan | Proud husband of | Father to my kids:
Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/8
On Tue, Feb 19, 2002 at 02:22:06PM +0100, [EMAIL PROTECTED] wrote:
> it even finds uninitialized variables.
it even does this transitively.
> I wonder why I have never heard
> of "valgrind" before.
it's new that's why :)
It's nice to see some dynamic binar
Hi,
this memory checker seems to be great! IMHO every LyX developer/tester
should use it. AFAIK it is the only real alternative to Purify so far as
it even finds uninitialized variables. I wonder why I have never heard
of "valgrind" before.
Thanks for the hint, John.
Michael
On Tue, Feb 19, 2002 at 01:17:26PM +1000, Allan Rae wrote:
> Finally a memory checker that works for me too!
you realise you are expected to fix all the bugs now :)
john
--
"They eat cold meat for breakfast and make jokes about gzip."
- Rik Hemsley on KDE developers
On Mon, 18 Feb 2002, John Levon wrote:
> On Mon, Feb 18, 2002 at 08:43:37PM +0100, Michael Schmitt wrote:
>
> > google does not know it and sourceforge provides an empty project.
>
> http://lists.kde.org/?l=kde-core-devel&m=101380460705928&w=2
>
> It's slowish for some things but has already repo
On Mon, Feb 18, 2002 at 08:43:37PM +0100, Michael Schmitt wrote:
> google does not know it and sourceforge provides an empty project.
http://lists.kde.org/?l=kde-core-devel&m=101380460705928&w=2
It's slowish for some things but has already reported a problem that
njamd didn't notice ...
regard
63 matches
Mail list logo
