Re: SIGSEGV on master regarding math completion
On Tue, Mar 08, 2022 at 04:20:34PM +0100, Jean-Marc Lasgouttes wrote: > Le 06/03/2022 à 19:55, Scott Kostyshak a écrit : > > It is not minimal, but I see the message when I open ch01.lyx, after > > lots of messages about modules not available, from the below ticket: > > > >https://www.lyx.org/trac/ticket/12486 > > Indeed, thanks. Should be fixed now. Thanks for the fix! Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SIGSEGV on master regarding math completion
Le 06/03/2022 à 19:55, Scott Kostyshak a écrit : It is not minimal, but I see the message when I open ch01.lyx, after lots of messages about modules not available, from the below ticket: https://www.lyx.org/trac/ticket/12486 Indeed, thanks. Should be fixed now. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SIGSEGV on master regarding math completion
On Tue, Jan 25, 2022 at 11:49:58AM -0500, Scott Kostyshak wrote: > On Tue, Jan 25, 2022 at 05:28:44PM +0100, Jean-Marc Lasgouttes wrote: > > Le 25/01/2022 à 17:23, Scott Kostyshak a écrit : > > > I have seen that terminal message on master in other contexts (I think > > > it had something to do with undefined layout insets). I guessed that it > > > was not a problem since it did not assert. Should I report an MWE > > > whenever I see that message? > > > > Yes please. It is mostly the sign that some undo code is not clean yet. > > Good to know, I'll keep an eye out for this and report it next time I > see it on master. It is not minimal, but I see the message when I open ch01.lyx, after lots of messages about modules not available, from the below ticket: https://www.lyx.org/trac/ticket/12486 Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SIGSEGV on master regarding math completion
On Fri, Jan 28, 2022 at 06:09:25PM +0100, Jean-Marc Lasgouttes wrote: > Le 28/01/2022 à 17:49, Kornel Benko a écrit : > > > This seems to work and makes sense. Could someone do a quick check > > > before I commit ? I will run it under valgrind later, when I am in front > > > of an old enough ubuntu box. > > > > Works well here. Compiled with -fsanitize, no problems. > > Thanks Kornel. I pushed it to master, we'll see. Works well here also, thanks. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SIGSEGV on master regarding math completion
Le 28/01/2022 à 17:49, Kornel Benko a écrit : This seems to work and makes sense. Could someone do a quick check before I commit ? I will run it under valgrind later, when I am in front of an old enough ubuntu box. Works well here. Compiled with -fsanitize, no problems. Thanks Kornel. I pushed it to master, we'll see. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SIGSEGV on master regarding math completion
Am Fri, 28 Jan 2022 17:17:40 +0100 schrieb Jean-Marc Lasgouttes : > Le 27/01/2022 à 17:26, Jean-Marc Lasgouttes a écrit : > > So finally, the MathRow object points to an inset that has been deleted > > at the time of the completion. There should be code somewhere that > > should regenerate the math row. I'll have a look. > > This seems to work and makes sense. Could someone do a quick check > before I commit ? I will run it under valgrind later, when I am in front > of an old enough ubuntu box. > > JMarc > > Works well here. Compiled with -fsanitize, no problems. Kornel pgp8CnoY49V0O.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SIGSEGV on master regarding math completion
Le 27/01/2022 à 17:26, Jean-Marc Lasgouttes a écrit : So finally, the MathRow object points to an inset that has been deleted at the time of the completion. There should be code somewhere that should regenerate the math row. I'll have a look. This seems to work and makes sense. Could someone do a quick check before I commit ? I will run it under valgrind later, when I am in front of an old enough ubuntu box. JMarc From f400a2cfa9b5552c103da0b7e336b6964dfa5b2d Mon Sep 17 00:00:00 2001 From: Jean-Marc Lasgouttes Date: Fri, 28 Jan 2022 17:13:30 +0100 Subject: [PATCH] Force redraw after completion Inside a math inset when completing macro names, it could lead to crashes. Note that this processUpdateFlags is present when outside of this if() branch. --- src/frontends/qt/GuiCompleter.cpp | 4 1 file changed, 4 insertions(+) diff --git a/src/frontends/qt/GuiCompleter.cpp b/src/frontends/qt/GuiCompleter.cpp index 6fd39d3039..6effd3d05b 100644 --- a/src/frontends/qt/GuiCompleter.cpp +++ b/src/frontends/qt/GuiCompleter.cpp @@ -701,6 +701,10 @@ void GuiCompleter::tab() hidePopup(); hideInline(cur); updateVisibility(false, false); + + // redraw if needed + if (cur.result().screenUpdate()) + gui_->bufferView().processUpdateFlags(cur.result().screenUpdate()); return; } docstring nextchar = completion.substr(prefix.size(), 1); -- 2.32.0 -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SIGSEGV on master regarding math completion
Le 27/01/2022 à 23:39, Scott Kostyshak a écrit : So finally, the MathRow object points to an inset that has been deleted at the time of the completion. There should be code somewhere that should regenerate the math row. I'll have a look. Thanks for walking this through! The only part you skipped over is what did you do during the 20 minutes of wait-time while running with Valgrind? :) Well, I launch LyX, go back to what I was doing and after 45s a LyX windows pops up. That's still in the livable territory. And it is great to detect memory issues like this one. I do hope to go back to trying Valgrind when I find bugs and I made a note to study this case when I do. It works quite well to detect memory issues like this one. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SIGSEGV on master regarding math completion
On Thu, Jan 27, 2022 at 05:26:33PM +0100, Jean-Marc Lasgouttes wrote: > Le 10/01/2022 à 03:49, Scott Kostyshak a écrit : > > To reproduce: > > > > 1. Start a new document. > > 2. Ctrl + m to start math inset. > > 3. Type \phantomx. Note that \phantomx is not a command so don't > > expect it to be recognized. > > 4. Press , , to delete the "x" and the "m". > > 5. Type "m" to finish "phantom". > > 6. Wait for the completion pop-down to appear (this takes a second). > > 7. Press . > > > > I tried to find a more simple recipe to reproduce but could not. > > So, on Ubuntu 20.04, valgrind is more useful. I attache the log below, but > here is the gist of it: > > 1/ the error > > ==2557222== Invalid read of size 8 > ==2557222==at 0xB3B5C1: lyx::Inset::isBufferValid() const > (Inset.cpp:230) > [...] > ==2557222==by 0xA1382F: lyx::RowPainter::paintInset(lyx::Row::Element > const&) const (RowPainter.cpp:116) > > Here one can see that the code in devel-mode that paints in red insets that > do not have a buffer looks at buffer methods. This does not work because... > > 2/ the culprit > > ==2557222== Address 0xf9e0708 is 8 bytes inside a block of size 32 free'd > ==2557222==at 0x483CFBF: operator delete(void*) (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2557222==by 0xA23A6E: lyx::InsetMathChar::~InsetMathChar() > (InsetMathChar.h:22) > [...] > lyx::InsetMathMacro::insertCompletion(lyx::Cursor&, > std::__cxx11::basic_string, > std::allocator > const&, bool) (InsetMathMacro.cpp:1376) > > We are pointing to an inset that has been deleted at completion time. > > > 3/ the context > > ==2557222== Block was alloc'd at > ==2557222==at 0x483BE63: operator new(unsigned long) (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2557222==by 0xA22447: lyx::InsetMathChar::clone() const > (InsetMathChar.cpp:104) > [...] > lyx::InsetMathMacro::setDisplayMode(lyx::InsetMathMacro::DisplayMode, int) > (InsetMathMacro.cpp:825) > > > > So finally, the MathRow object points to an inset that has been deleted at > the time of the completion. There should be code somewhere that should > regenerate the math row. I'll have a look. Thanks for walking this through! The only part you skipped over is what did you do during the 20 minutes of wait-time while running with Valgrind? :) I do hope to go back to trying Valgrind when I find bugs and I made a note to study this case when I do. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SIGSEGV on master regarding math completion
Le 10/01/2022 à 03:49, Scott Kostyshak a écrit : To reproduce: 1. Start a new document. 2. Ctrl + m to start math inset. 3. Type \phantomx. Note that \phantomx is not a command so don't expect it to be recognized. 4. Press , , to delete the "x" and the "m". 5. Type "m" to finish "phantom". 6. Wait for the completion pop-down to appear (this takes a second). 7. Press . I tried to find a more simple recipe to reproduce but could not. So, on Ubuntu 20.04, valgrind is more useful. I attache the log below, but here is the gist of it: 1/ the error ==2557222== Invalid read of size 8 ==2557222==at 0xB3B5C1: lyx::Inset::isBufferValid() const (Inset.cpp:230) [...] ==2557222==by 0xA1382F: lyx::RowPainter::paintInset(lyx::Row::Element const&) const (RowPainter.cpp:116) Here one can see that the code in devel-mode that paints in red insets that do not have a buffer looks at buffer methods. This does not work because... 2/ the culprit ==2557222== Address 0xf9e0708 is 8 bytes inside a block of size 32 free'd ==2557222==at 0x483CFBF: operator delete(void*) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==2557222==by 0xA23A6E: lyx::InsetMathChar::~InsetMathChar() (InsetMathChar.h:22) [...] lyx::InsetMathMacro::insertCompletion(lyx::Cursor&, std::__cxx11::basic_string, std::allocator > const&, bool) (InsetMathMacro.cpp:1376) We are pointing to an inset that has been deleted at completion time. 3/ the context ==2557222== Block was alloc'd at ==2557222==at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==2557222==by 0xA22447: lyx::InsetMathChar::clone() const (InsetMathChar.cpp:104) [...] lyx::InsetMathMacro::setDisplayMode(lyx::InsetMathMacro::DisplayMode, int) (InsetMathMacro.cpp:825) So finally, the MathRow object points to an inset that has been deleted at the time of the completion. There should be code somewhere that should regenerate the math row. I'll have a look. JMarc==2557222== Memcheck, a memory error detector ==2557222== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==2557222== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==2557222== Command: src/lyx ==2557222== --2557222-- WARNING: unhandled amd64-linux syscall: 315 --2557222-- You may be able to write your own handler. --2557222-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --2557222-- Nevertheless we consider this a bug. Please report --2557222-- it at http://valgrind.org/support/bug_reports.html. ==2557222== Invalid read of size 8 ==2557222==at 0xB3B5C1: lyx::Inset::isBufferValid() const (Inset.cpp:230) ==2557222==by 0xAEDCB1: lyx::MathRow::draw(lyx::PainterInfo&, int, int) const (MathRow.cpp:327) ==2557222==by 0xAAEB8B: lyx::MathData::draw(lyx::PainterInfo&, int, int) const (MathData.cpp:356) ==2557222==by 0xA6ABA4: lyx::InsetMathMacro::draw(lyx::PainterInfo&, int, int) const (InsetMathMacro.cpp:756) ==2557222==by 0xAED744: lyx::MathRow::draw(lyx::PainterInfo&, int, int) const (MathRow.cpp:330) ==2557222==by 0xAAEB8B: lyx::MathData::draw(lyx::PainterInfo&, int, int) const (MathData.cpp:356) ==2557222==by 0xA30FAC: lyx::InsetMathGrid::draw(lyx::PainterInfo&, int, int) const (InsetMathGrid.cpp:601) ==2557222==by 0xA4E187: lyx::InsetMathHull::draw(lyx::PainterInfo&, int, int) const (InsetMathHull.cpp:667) ==2557222==by 0xA1382F: lyx::RowPainter::paintInset(lyx::Row::Element const&) const (RowPainter.cpp:116) ==2557222==by 0xA14BBF: lyx::RowPainter::paintText() (RowPainter.cpp:563) ==2557222==by 0x909ABF: lyx::TextMetrics::drawParagraph(lyx::PainterInfo&, long, int, int) const (TextMetrics.cpp:2074) ==2557222==by 0x90CE4C: lyx::TextMetrics::draw(lyx::PainterInfo&, int, int) const (TextMetrics.cpp:1919) ==2557222== Address 0xf9e0708 is 8 bytes inside a block of size 32 free'd ==2557222==at 0x483CFBF: operator delete(void*) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==2557222==by 0xA23A6E: lyx::InsetMathChar::~InsetMathChar() (InsetMathChar.h:22) ==2557222==by 0xAA3866: operator() (unique_ptr.h:81) ==2557222==by 0xAA3866: reset (unique_ptr.h:402) ==2557222==by 0xAA3866: operator= (unique_ptr.h:307) ==2557222==by 0xAA3866: operator= (MathAtom.h:49) ==2557222==by 0xAA3866: lyx::MathAtom::operator=(lyx::MathAtom const&) (MathAtom.cpp:34) ==2557222==by 0xA1F520: __copy_m (stl_algobase.h:342) ==2557222==by 0xA1F520: __copy_move_a (stl_algobase.h:404) ==2557222==by 0xA1F520: __copy_move_a2 > >, __gnu_cxx::__normal_iterator > > > (stl_algobase.h:440) ==2557222==by 0xA1F520: copy<__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > > > (stl_algobase.h:474) ==2557222==by 0xA1F520: std::__cxx1998::vector >::operator=(std::__cxx1998::vector > const&) (vector.tcc:238) ==2557222==by 0xAD7D7E:
Re: SIGSEGV on master regarding math completion
On Tue, Jan 25, 2022 at 05:28:44PM +0100, Jean-Marc Lasgouttes wrote: > Le 25/01/2022 à 17:23, Scott Kostyshak a écrit : > > I have seen that terminal message on master in other contexts (I think > > it had something to do with undefined layout insets). I guessed that it > > was not a problem since it did not assert. Should I report an MWE > > whenever I see that message? > > Yes please. It is mostly the sign that some undo code is not clean yet. Good to know, I'll keep an eye out for this and report it next time I see it on master. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SIGSEGV on master regarding math completion
Le 25/01/2022 à 17:23, Scott Kostyshak a écrit : I have seen that terminal message on master in other contexts (I think it had something to do with undefined layout insets). I guessed that it was not a problem since it did not assert. Should I report an MWE whenever I see that message? Yes please. It is mostly the sign that some undo code is not clean yet. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SIGSEGV on master regarding math completion
On Tue, Jan 25, 2022 at 05:12:06PM +0100, Jean-Marc Lasgouttes wrote: > Le 25/01/2022 à 16:07, Scott Kostyshak a écrit : > > On testing a different commit I received the following terminal message: > > > >Undo.cpp (319): There is no group open (creating one) > > If you can reproduce this, I am interested. It is reproducible but I think my message was not clear. By "a different commit" I mean "an older commit", and wanted to give the idea that I'm not sure the bisect would be linear (because of several differences in behavior). I can reproduce that terminal message with the commit cc0ef52a (2019-01-14). I cannot reproduce that message on master with the original recipe. I have seen that terminal message on master in other contexts (I think it had something to do with undefined layout insets). I guessed that it was not a problem since it did not assert. Should I report an MWE whenever I see that message? Scott > > JMarc, the backtrace suggests that painting code is involved. If a > > bisect would be helpful, which change of behavior should I bisect? > > The problem seems to be that the inset is created without setting properly > its buffer. And the drawing code uses the value of this buffer. > > JMarc > > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SIGSEGV on master regarding math completion
Le 25/01/2022 à 16:07, Scott Kostyshak a écrit : On testing a different commit I received the following terminal message: Undo.cpp (319): There is no group open (creating one) If you can reproduce this, I am interested. JMarc, the backtrace suggests that painting code is involved. If a bisect would be helpful, which change of behavior should I bisect? The problem seems to be that the inset is created without setting properly its buffer. And the drawing code uses the value of this buffer. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SIGSEGV on master regarding math completion
On Mon, Jan 24, 2022 at 10:56:50AM +0100, Pavel Sanda wrote: > On Thu, Jan 20, 2022 at 09:40:21PM -0500, Scott Kostyshak wrote: > > > To reproduce: > > > > > > 1. Start a new document. > > > 2. Ctrl + m to start math inset. > > > 3. Type \phantomx. Note that \phantomx is not a command so don't > > >expect it to be recognized. > > > 4. Press , , to delete the "x" and the "m". > > > 5. Type "m" to finish "phantom". > > > 6. Wait for the completion pop-down to appear (this takes a second). > > > 7. Press . > > > > > > I tried to find a more simple recipe to reproduce but could not. > > > > > > The result is that I get a SIGSEGV. Backtrace is attached. > > > > Can anyone reproduce? > > I can reproduce. Thanks. > > I cannot reproduce on 2.3.0, but the 2.3.0 behavior is not ideal either. > > After (7) there's no crash but also the phantom inset is not created. > > That said, if it would be helpful for me to spend time on a bisect I > > don't mind. > > That would be definitely helpful. I just took a look and there are several differences in behavior. 2.3.x shows a different behavior than 2.3.0: it leaves the space for "\phantom" to be drawn but it is not drawn. However, there is no crash. On testing a different commit I received the following terminal message: Undo.cpp (319): There is no group open (creating one) JMarc, the backtrace suggests that painting code is involved. If a bisect would be helpful, which change of behavior should I bisect? Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SIGSEGV on master regarding math completion
On Thu, Jan 20, 2022 at 09:40:21PM -0500, Scott Kostyshak wrote: > > To reproduce: > > > > 1. Start a new document. > > 2. Ctrl + m to start math inset. > > 3. Type \phantomx. Note that \phantomx is not a command so don't > >expect it to be recognized. > > 4. Press , , to delete the "x" and the "m". > > 5. Type "m" to finish "phantom". > > 6. Wait for the completion pop-down to appear (this takes a second). > > 7. Press . > > > > I tried to find a more simple recipe to reproduce but could not. > > > > The result is that I get a SIGSEGV. Backtrace is attached. > > Can anyone reproduce? I can reproduce. > I cannot reproduce on 2.3.0, but the 2.3.0 behavior is not ideal either. > After (7) there's no crash but also the phantom inset is not created. > That said, if it would be helpful for me to spend time on a bisect I > don't mind. That would be definitely helpful. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SIGSEGV on master regarding math completion
On Sun, Jan 09, 2022 at 09:49:26PM -0500, Scott Kostyshak wrote: > To reproduce: > > 1. Start a new document. > 2. Ctrl + m to start math inset. > 3. Type \phantomx. Note that \phantomx is not a command so don't >expect it to be recognized. > 4. Press , , to delete the "x" and the "m". > 5. Type "m" to finish "phantom". > 6. Wait for the completion pop-down to appear (this takes a second). > 7. Press . > > I tried to find a more simple recipe to reproduce but could not. > > The result is that I get a SIGSEGV. Backtrace is attached. Can anyone reproduce? I cannot reproduce on 2.3.0, but the 2.3.0 behavior is not ideal either. After (7) there's no crash but also the phantom inset is not created. That said, if it would be helpful for me to spend time on a bisect I don't mind. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
SIGSEGV on master regarding math completion
To reproduce: 1. Start a new document. 2. Ctrl + m to start math inset. 3. Type \phantomx. Note that \phantomx is not a command so don't expect it to be recognized. 4. Press , , to delete the "x" and the "m". 5. Type "m" to finish "phantom". 6. Wait for the completion pop-down to appear (this takes a second). 7. Press . I tried to find a more simple recipe to reproduce but could not. The result is that I get a SIGSEGV. Backtrace is attached. Just before the SIGSEGV the terminal prints the following output (I think from fsanitize). I don't think the output contains extra information since the backtrace points to the same line number, but just in case: /home/scott/lyxbuilds/master/repo/src/mathed/MathRow.cpp:330:17: runtime error: member call on address 0x5edd6970 which does not point to an object of type 'Inset' 0x5edd6970: note: object has invalid vptr 00 00 00 00 d6 ed 55 55 05 00 00 00 32 7c 78 c2 e2 a1 20 d3 6d 00 00 00 00 00 00 00 00 00 00 00 ^~~ invalid vptr /home/scott/lyxbuilds/master/repo/src/mathed/MathRow.cpp:330:17: runtime error: load of misaligned address 0x0005eeb6 for type ' *', which requires 8 byte alignment 0x0005eeb6: note: pointer points here Scott Thread 1 "lyx" received signal SIGSEGV, Segmentation fault. 0x597bab3b in lyx::MathRow::draw (this=0x5ea908a0, pi=..., x=262, y=84) at /home/scott/lyxbuilds/master/repo/src/mathed/MathRow.cpp:330 330 e.inset->draw(pi, x + e.before, y); (gdb) bt #0 0x597bab3b in lyx::MathRow::draw(lyx::PainterInfo&, int, int) const (this=0x5ea908a0, pi=..., x=262, y=84) at /home/scott/lyxbuilds/master/repo/src/mathed/MathRow.cpp:330 #1 0x59730013 in lyx::MathData::draw(lyx::PainterInfo&, int, int) const (this=0x5ecc1a10, pi=..., x=138, y=84) at /home/scott/lyxbuilds/master/repo/src/mathed/MathData.cpp:356 #2 0x5964af78 in lyx::InsetMathMacro::draw(lyx::PainterInfo&, int, int) const (this=0x5eddbe50, pi=..., x=138, y=84) at /home/scott/lyxbuilds/master/repo/src/mathed/InsetMathMacro.cpp:756 #3 0x597bad20 in lyx::MathRow::draw(lyx::PainterInfo&, int, int) const (this=0x5ecbde90, pi=..., x=123, y=84) at /home/scott/lyxbuilds/master/repo/src/mathed/MathRow.cpp:330 #4 0x59730013 in lyx::MathData::draw(lyx::PainterInfo&, int, int) const (this=0x5e910a80, pi=..., x=123, y=84) at /home/scott/lyxbuilds/master/repo/src/mathed/MathData.cpp:356 #5 0x5957c9f9 in lyx::InsetMathGrid::draw(lyx::PainterInfo&, int, int) const (this=0x5d579400, pi=..., x=123, y=84) at /home/scott/lyxbuilds/master/repo/src/mathed/InsetMathGrid.cpp:601 #6 0x595daa08 in lyx::InsetMathHull::draw(lyx::PainterInfo&, int, int) const (this=0x5d579400, pi=..., x=122, y=84) at /home/scott/lyxbuilds/master/repo/src/mathed/InsetMathHull.cpp:667 #7 0x591d6767 in lyx::RowPainter::paintInset(lyx::Row::Element const&) const (this=0x7fffc5e0, e=...) at /home/scott/lyxbuilds/master/repo/src/RowPainter.cpp:116 #8 0x591e7d74 in lyx::RowPainter::paintText() (this=0x7fffc5e0) at /home/scott/lyxbuilds/master/repo/src/RowPainter.cpp:563 #9 0x5935f4c5 in lyx::TextMetrics::drawParagraph(lyx::PainterInfo&, long, int, int) const (this=0x5edd8ac8, pi=..., pit=0, x=0, y=84) at /home/scott/lyxbuilds/master/repo/src/TextMetrics.cpp:2085 #10 0x5935be80 in lyx::TextMetrics::draw(lyx::PainterInfo&, int, int) const (this=0x5edd8ac8, pi=..., x=0, y=84) at /home/scott/lyxbuilds/master/repo/src/TextMetrics.cpp:1930 #11 0x58cf03c3 in lyx::BufferView::draw(lyx::frontend::Painter&, bool) (this=0x5e7ce2b0, pain=..., paint_caret=false) at /home/scott/lyxbuilds/master/repo/src/BufferView.cpp:3469 #12 0x59fa3bde in lyx::frontend::GuiWorkArea::paintEvent(QPaintEvent*) (this=0x5e7d7830, ev=0x7fffce00) at /home/scott/lyxbuilds/master/repo/src/frontends/qt/GuiWorkArea.cpp:1290 #13 0x7780e17e in QWidget::event(QEvent*) () at /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #14 0x778bbb52 in QFrame::event(QEvent*) () at /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #15 0x76cdceca in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) (event=, receiver=) at kernel/qcoreapplication.cpp:1189 #16 QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) (receiver=0x5e7e7900, event=0x7fffce00) at kernel/qcoreapplication.cpp:1178 #17 0x777cb6a2 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #18 0x59e098ac in lyx::frontend::GuiApplication::notify(QObject*, QEvent*) (this=0x5d4af960, receiver=0x5e7e7900, event=0x7fffce00) at /home/scott/lyxbuilds/master/repo/src/frontends/qt/GuiApplication.cpp:3000 #19 0x76cdd16a in QCoreApplication::notifyInternal2(QObject*, QEvent*)
