Re: Bug in Lyx 1.3.4 ?
Am 10.02.2020 um 22:01 schrieb Enrico Forestieri : > > On Mon, Feb 10, 2020 at 01:00:11PM +0100, Stephan Witt wrote: > >> Am 07.02.2020 um 08:32 schrieb Enrico Forestieri : >>> >>> On Thu, Feb 06, 2020 at 10:36:30PM +0100, Stephan Witt wrote: But some cases I’d like to point out: InsetMathSpace::doDispatch() calls createInsetMath_fromDialogStr() createInsetMath_fromDialogStr calls mathed_parse_cell() mathed_parse_cell() calls Parser() with NULL buffer Similar is the call to createInsetMath_fromDialogStr in InsetMathRef::doDispatch() and InsetMathRef::changeTarget(). These look dangerous too, IMO. What do you think? Do you know how to trigger this pieces of code? >>> >>> It is hard to tell how dangerous they are. As said, in most cases the >>> validity of the buffer member is checked before being used. So, having >>> a null there is not troublesome for most code paths. However, it can >>> bite in certain cases. In the case at hand, the buffer has always been >>> null but, not being used in certain code paths, it has never been a >>> problem. >> >> I see a problem in Parser::parse1(). >> (The line numbers are in master as of today b8546139c8) >> >> The code block below line 1983 uses the buffer member. >> At line 1986 and 1990 there is a NULL pointer check but at line 2086 >> the check is missing. This has to be corrected IMO. > > Done at 536d476d. > >> BTW, the value assigned to num_tokens in line 2092 is not used >> because it’s defined local at line 2055 and used only in else block >> at line 2105. > > Those assignments were added at 1a6c5999 and I agree that they are > superfluous. Removed at 926c846a. Thank you for your review and the corrections. Stephan -- lyx-devel mailing list [email protected] http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bug in Lyx 1.3.4 ?
On Mon, Feb 10, 2020 at 01:00:11PM +0100, Stephan Witt wrote: > Am 07.02.2020 um 08:32 schrieb Enrico Forestieri : > > > > On Thu, Feb 06, 2020 at 10:36:30PM +0100, Stephan Witt wrote: > >> But some cases I’d like to point out: > >> > >> InsetMathSpace::doDispatch() calls createInsetMath_fromDialogStr() > >> createInsetMath_fromDialogStr calls mathed_parse_cell() > >> mathed_parse_cell() calls Parser() with NULL buffer > >> > >> Similar is the call to createInsetMath_fromDialogStr in > >> InsetMathRef::doDispatch() and InsetMathRef::changeTarget(). > >> > >> These look dangerous too, IMO. What do you think? > >> Do you know how to trigger this pieces of code? > > > > It is hard to tell how dangerous they are. As said, in most cases the > > validity of the buffer member is checked before being used. So, having > > a null there is not troublesome for most code paths. However, it can > > bite in certain cases. In the case at hand, the buffer has always been > > null but, not being used in certain code paths, it has never been a > > problem. > > I see a problem in Parser::parse1(). > (The line numbers are in master as of today b8546139c8) > > The code block below line 1983 uses the buffer member. > At line 1986 and 1990 there is a NULL pointer check but at line 2086 > the check is missing. This has to be corrected IMO. Done at 536d476d. > BTW, the value assigned to num_tokens in line 2092 is not used > because it’s defined local at line 2055 and used only in else block > at line 2105. Those assignments were added at 1a6c5999 and I agree that they are superfluous. Removed at 926c846a. -- Enrico -- lyx-devel mailing list [email protected] http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bug in Lyx 1.3.4 ?
Am 07.02.2020 um 08:32 schrieb Enrico Forestieri : > > On Thu, Feb 06, 2020 at 10:36:30PM +0100, Stephan Witt wrote: >> But some cases I’d like to point out: >> >> InsetMathSpace::doDispatch() calls createInsetMath_fromDialogStr() >> createInsetMath_fromDialogStr calls mathed_parse_cell() >> mathed_parse_cell() calls Parser() with NULL buffer >> >> Similar is the call to createInsetMath_fromDialogStr in >> InsetMathRef::doDispatch() and InsetMathRef::changeTarget(). >> >> These look dangerous too, IMO. What do you think? >> Do you know how to trigger this pieces of code? > > It is hard to tell how dangerous they are. As said, in most cases the > validity of the buffer member is checked before being used. So, having > a null there is not troublesome for most code paths. However, it can > bite in certain cases. In the case at hand, the buffer has always been > null but, not being used in certain code paths, it has never been a > problem. I see a problem in Parser::parse1(). (The line numbers are in master as of today b8546139c8) The code block below line 1983 uses the buffer member. At line 1986 and 1990 there is a NULL pointer check but at line 2086 the check is missing. This has to be corrected IMO. BTW, the value assigned to num_tokens in line 2092 is not used because it’s defined local at line 2055 and used only in else block at line 2105. Stephan -- lyx-devel mailing list [email protected] http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bug in Lyx 1.3.4 ?
Am 08.02.2020 um 12:54 schrieb Emile Lunardon :
>
> Thank you for this confirmation. The problem occurs well on Linux, Windows
> and macOS
> systems.
>
> Do you mind to submit the Bug report as you have proposed a patch to correct
> it ?
I don’t think we need a bug report. There is a similar case in bug 11729
mentioned.
Because of your report and another important bug on windows (11728) we are
working
on a patch release already. Hopefully it will be released soon.
Thank you for your report again.
Best regards,
Stephan
>
> Best regards
>
>
>
> Le jeu. 6 févr. 2020 à 00:18, Stephan Witt a écrit :
> > Am 05.02.2020 um 23:33 schrieb emile lunardon :
> >
> > I have installed LyX 2.3.4 on Windows10 and the same crash already seen on
> > LyX for Linux occurs when trying to enter the two Math Symbols :
> > $\textrm{Ø}\textrm{Å}$
> >
> > Le mer. 5 févr. 2020 à 08:32, emile lunardon a
> > écrit :
> > When I try to enter, under LyX 1.3.4 (Linux), one of the two Math symbols
> > shown in the attached file (written with LyX 1.3.3), there is a crash of
> > LyX 1.3.4 with the attached messages.
> >
> > Can someone confirm this strange phenomena ?
>
> I can confirm your bug with Qt5 on macOS with LyX 2.3.4. I think this is the
> version you’re talking about all the time.
>
> One has to use the math toolbar and there choose the symbol Å from the
> miscellaneous pane.
>
> The backtrace is:
>
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
> (code=1, address=0x18)
> frame #0: 0x0001000699dc
> LyX`lyx::Buffer::params(this=0x) at Buffer.cpp:719:9
> frame #1: 0x00010079fa18 LyX`lyx::(anonymous
> namespace)::Parser::parse1(this=0x7ffeefbf5b20, grid=0x7ffeefbf23e0,
> flags=128, mode=TEXT_MODE, numbered=false) at MathParser.cpp:2080:20
> * frame #2: 0x000100790987 LyX`lyx::(anonymous
> namespace)::Parser::parse(this=0x7ffeefbf5b20, array=0x000113353690,
> flags=64, mode=TEXT_MODE) at MathParser.cpp:782:2
> frame #3: 0x00010079f18c LyX`lyx::(anonymous
> namespace)::Parser::parse1(this=0x7ffeefbf5b20, grid=0x7ffeefbf5a30,
> flags=0, mode=MATH_MODE, numbered=false) at MathParser.cpp:2013:6
> frame #4: 0x000100790987 LyX`lyx::(anonymous
> namespace)::Parser::parse(this=0x7ffeefbf5b20, array=0x7ffeefbf6530,
> flags=0, mode=MATH_MODE) at MathParser.cpp:782:2
> frame #5: 0x000100790874
> LyX`lyx::mathed_parse_cell(ar=0x7ffeefbf6530, str=L"\\textrm \\AA",
> f=NORMAL) at MathParser.cpp:2156:37
> frame #6: 0x0001007c28d2 LyX`lyx::asArray(str=L"\\textrm \\AA",
> ar=0x7ffeefbf6530, pf=NORMAL) at MathSupport.cpp:990:38
> frame #7: 0x0001006deba4
> LyX`lyx::InsetMathNest::doDispatch(this=0x0001112cde10,
> cur=0x000106149098, cmd=0x7ffeefbf9068) at InsetMathNest.cpp:1237:4
> frame #8: 0x00010065baa2
> LyX`lyx::InsetMathGrid::doDispatch(this=0x0001112cde10,
> cur=0x000106149098, cmd=0x7ffeefbf9068) at InsetMathGrid.cpp:1733:18
> frame #9: 0x00010067e615
> LyX`lyx::InsetMathHull::doDispatch(this=0x0001112cde10,
> cur=0x000106149098, cmd=0x7ffeefbf9068) at InsetMathHull.cpp:2024:18
> frame #10: 0x000100811520
> LyX`lyx::Inset::dispatch(this=0x0001112cde10, cur=0x000106149098,
> cmd=0x7ffeefbf9068) at Inset.cpp:325:2
> frame #11: 0x0001001e018b
> LyX`lyx::Cursor::dispatch(this=0x000106149098, cmd0=0x00011123dd68)
> at Cursor.cpp:337:11
> frame #12: 0x000100d876b4
> LyX`lyx::frontend::GuiView::dispatchToBufferView(this=0x00011159b6f0,
> cmd=0x00011123dd68, dr=0x7ffeefbfc7a0) at GuiView.cpp:3687:15
> frame #13: 0x000100d80df6
> LyX`lyx::frontend::GuiView::dispatch(this=0x00011159b6f0,
> cmd=0x00011123dd68, dr=0x7ffeefbfc7a0) at GuiView.cpp:4343:4
> frame #14: 0x000100a96008
> LyX`lyx::frontend::GuiApplication::dispatch(this=0x000105d0a1d0,
> cmd=0x00011123dd68, dr=0x7ffeefbfc7a0) at GuiApplication.cpp:2076:19
> frame #15: 0x000100a8ff88
> LyX`lyx::frontend::GuiApplication::dispatch(this=0x000105d0a1d0,
> cmd=0x00011123dd68) at GuiApplication.cpp:1405:3
> frame #16: 0x00010037a4ea
> LyX`lyx::dispatch(action=0x00011123dd68) at LyX.cpp:1462:19
> frame #17: 0x000100a41c4b
> LyX`lyx::frontend::Action::action(this=0x00011334a560) at Action.cpp:87:2
> frame #18: 0x000100a41d51
> LyX`lyx::frontend::Action::qt_static_metacall(_o=0x00011334a560,
> _c=InvokeMetaMethod, _id=1, _a=0x7ffeefbfc970) at moc_Action.cpp:81:21
> frame #19: 0x00010554d63a QtCore`QMetaObject::activate(QObject*, int,
> int, void**) + 2298
> frame #20: 0x00010474e185
> QtWidgets`QAction::activate(QAction::ActionEvent) + 309
> frame #21: 0x000104841be3 QtWidgets`QAbstractButtonPrivate::click() +
> 147
> frame #22: 0x000104842d6c
> Qt
Re: Bug in Lyx 1.3.4 ?
On 2/8/20 9:57 AM, Jürgen Spitzmüller wrote: > Am Freitag, den 07.02.2020, 10:21 +0100 schrieb Stephan Witt: >> I’ve commit and pushed the fix to master (59fa0b2592). > This should also go to stable. He did that, and I've cherry picked it. Riki -- lyx-devel mailing list [email protected] http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bug in Lyx 1.3.4 ?
Am Freitag, den 07.02.2020, 10:21 +0100 schrieb Stephan Witt: > I’ve commit and pushed the fix to master (59fa0b2592). This should also go to stable. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list [email protected] http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bug in Lyx 1.3.4 ?
Thank you for this confirmation. The problem occurs well on Linux, Windows
and macOS
systems.
Do you mind to submit the Bug report as you have proposed a patch to
correct it ?
Best regards
Le jeu. 6 févr. 2020 à 00:18, Stephan Witt a écrit :
> > Am 05.02.2020 um 23:33 schrieb emile lunardon >:
> >
> > I have installed LyX 2.3.4 on Windows10 and the same crash already seen
> on LyX for Linux occurs when trying to enter the two Math Symbols :
> $\textrm{Ø}\textrm{Å}$
> >
> > Le mer. 5 févr. 2020 à 08:32, emile lunardon
> a écrit :
> > When I try to enter, under LyX 1.3.4 (Linux), one of the two Math
> symbols shown in the attached file (written with LyX 1.3.3), there is a
> crash of LyX 1.3.4 with the attached messages.
> >
> > Can someone confirm this strange phenomena ?
>
> I can confirm your bug with Qt5 on macOS with LyX 2.3.4. I think this is
> the version you’re talking about all the time.
>
> One has to use the math toolbar and there choose the symbol Å from the
> miscellaneous pane.
>
> The backtrace is:
>
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
> (code=1, address=0x18)
> frame #0: 0x0001000699dc
> LyX`lyx::Buffer::params(this=0x) at Buffer.cpp:719:9
> frame #1: 0x00010079fa18 LyX`lyx::(anonymous
> namespace)::Parser::parse1(this=0x7ffeefbf5b20,
> grid=0x7ffeefbf23e0, flags=128, mode=TEXT_MODE, numbered=false) at
> MathParser.cpp:2080:20
> * frame #2: 0x000100790987 LyX`lyx::(anonymous
> namespace)::Parser::parse(this=0x7ffeefbf5b20,
> array=0x000113353690, flags=64, mode=TEXT_MODE) at MathParser.cpp:782:2
> frame #3: 0x00010079f18c LyX`lyx::(anonymous
> namespace)::Parser::parse1(this=0x7ffeefbf5b20,
> grid=0x7ffeefbf5a30, flags=0, mode=MATH_MODE, numbered=false) at
> MathParser.cpp:2013:6
> frame #4: 0x000100790987 LyX`lyx::(anonymous
> namespace)::Parser::parse(this=0x7ffeefbf5b20,
> array=0x7ffeefbf6530, flags=0, mode=MATH_MODE) at MathParser.cpp:782:2
> frame #5: 0x000100790874
> LyX`lyx::mathed_parse_cell(ar=0x7ffeefbf6530, str=L"\\textrm \\AA",
> f=NORMAL) at MathParser.cpp:2156:37
> frame #6: 0x0001007c28d2 LyX`lyx::asArray(str=L"\\textrm \\AA",
> ar=0x7ffeefbf6530, pf=NORMAL) at MathSupport.cpp:990:38
> frame #7: 0x0001006deba4
> LyX`lyx::InsetMathNest::doDispatch(this=0x0001112cde10,
> cur=0x000106149098, cmd=0x7ffeefbf9068) at InsetMathNest.cpp:1237:4
> frame #8: 0x00010065baa2
> LyX`lyx::InsetMathGrid::doDispatch(this=0x0001112cde10,
> cur=0x000106149098, cmd=0x7ffeefbf9068) at InsetMathGrid.cpp:1733:18
> frame #9: 0x00010067e615
> LyX`lyx::InsetMathHull::doDispatch(this=0x0001112cde10,
> cur=0x000106149098, cmd=0x7ffeefbf9068) at InsetMathHull.cpp:2024:18
> frame #10: 0x000100811520
> LyX`lyx::Inset::dispatch(this=0x0001112cde10, cur=0x000106149098,
> cmd=0x7ffeefbf9068) at Inset.cpp:325:2
> frame #11: 0x0001001e018b
> LyX`lyx::Cursor::dispatch(this=0x000106149098, cmd0=0x00011123dd68)
> at Cursor.cpp:337:11
> frame #12: 0x000100d876b4
> LyX`lyx::frontend::GuiView::dispatchToBufferView(this=0x00011159b6f0,
> cmd=0x00011123dd68, dr=0x7ffeefbfc7a0) at GuiView.cpp:3687:15
> frame #13: 0x000100d80df6
> LyX`lyx::frontend::GuiView::dispatch(this=0x00011159b6f0,
> cmd=0x00011123dd68, dr=0x7ffeefbfc7a0) at GuiView.cpp:4343:4
> frame #14: 0x000100a96008
> LyX`lyx::frontend::GuiApplication::dispatch(this=0x000105d0a1d0,
> cmd=0x00011123dd68, dr=0x7ffeefbfc7a0) at GuiApplication.cpp:2076:19
> frame #15: 0x000100a8ff88
> LyX`lyx::frontend::GuiApplication::dispatch(this=0x000105d0a1d0,
> cmd=0x00011123dd68) at GuiApplication.cpp:1405:3
> frame #16: 0x00010037a4ea
> LyX`lyx::dispatch(action=0x00011123dd68) at LyX.cpp:1462:19
> frame #17: 0x000100a41c4b
> LyX`lyx::frontend::Action::action(this=0x00011334a560) at
> Action.cpp:87:2
> frame #18: 0x000100a41d51
> LyX`lyx::frontend::Action::qt_static_metacall(_o=0x00011334a560,
> _c=InvokeMetaMethod, _id=1, _a=0x7ffeefbfc970) at moc_Action.cpp:81:21
> frame #19: 0x00010554d63a QtCore`QMetaObject::activate(QObject*,
> int, int, void**) + 2298
> frame #20: 0x00010474e185
> QtWidgets`QAction::activate(QAction::ActionEvent) + 309
> frame #21: 0x000104841be3
> QtWidgets`QAbstractButtonPrivate::click() + 147
> frame #22: 0x000104842d6c
> QtWidgets`QAbstractButton::mouseReleaseEvent(QMouseEvent*) + 268
> frame #23: 0x000104939bbf
> QtWidgets`QToolButton::mouseReleaseEvent(QMouseEvent*) + 15
> frame #24: 0x0001047931d2 QtWidgets`QWidget::event(QEvent*) + 450
> frame #25: 0x00010493a14f QtWidgets`QToolButton::event(QEvent*) +
> 319
> frame #26: 0x0001047576ff
> QtWidgets`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 2
Re: Bug in Lyx 1.3.4 ?
Le 07/02/2020 à 08:32, Enrico Forestieri a écrit : On Thu, Feb 06, 2020 at 10:36:30PM +0100, Stephan Witt wrote: But some cases I’d like to point out: InsetMathSpace::doDispatch() calls createInsetMath_fromDialogStr() createInsetMath_fromDialogStr calls mathed_parse_cell() mathed_parse_cell() calls Parser() with NULL buffer Similar is the call to createInsetMath_fromDialogStr in InsetMathRef::doDispatch() and InsetMathRef::changeTarget(). These look dangerous too, IMO. What do you think? Do you know how to trigger this pieces of code? It is hard to tell how dangerous they are. As said, in most cases the validity of the buffer member is checked before being used. So, having a null there is not troublesome for most code paths. However, it can bite in certain cases. In the case at hand, the buffer has always been null but, not being used in certain code paths, it has never been a problem. Note that in master the background of insets that do not have a valid buffer_ is marked in red. I am not sure how effective it is in mathed, but it works in text. This check is only active in devel-mode (which can be toggled now). JMarc -- lyx-devel mailing list [email protected] http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bug in Lyx 1.3.4 ?
Am 06.02.2020 um 20:54 schrieb Richard Kimberly Heck : > > On 2/6/20 2:46 PM, Enrico Forestieri wrote: >> On Thu, Feb 06, 2020 at 01:53:34PM -0500, Richard Kimberly Heck wrote: >>> On 2/6/20 9:58 AM, Enrico Forestieri wrote: On Thu, Feb 06, 2020 at 01:52:15PM +0100, Pavel Sanda wrote: > On Thu, Feb 06, 2020 at 08:15:45AM +0100, Stephan Witt wrote: >> Am 06.02.2020 um 01:02 schrieb Richard Kimberly Heck : >>> I assume this is an old bug? Or is it a new one? >> I can reproduce something similar with 2.4.0 too. But I cannot reproduce >> with 2.2.4. > I can confirm it with Qt5 now. > Bisect leads to: > > commit a2d181905a95b3bb983dac60f3d9603413a01f34 > Author: Enrico Forestieri > Date: Tue Jun 25 22:23:51 2019 +0200 > >Fix bug #11586 > >Do not replace a latex command with the corresponding symbol >in the unicodesymbols file unless it can be encoded in the >document encoding. That commit simply exposes the bug, which is the fact that the buffer member is not initialized. I think the patch by Stephan is correct. >>> Does this warrant an emergency release? >> I would say so. The program cannot crash simply because a toolbar is >> used. I am surprised that it did not show up earlier, though. > > My thinking, too. > > If someone can commit the fix, I'll produce new tarballs this weekend > and we can aim for an emergency release early next week. I’ve commit and pushed the fix to master (59fa0b2592). IMO there are other cases of this as well. But I think they are less exposed to users and I cannot test then ATM because of a missing use case. Stephan -- lyx-devel mailing list [email protected] http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bug in Lyx 1.3.4 ?
On Thu, Feb 06, 2020 at 10:36:30PM +0100, Stephan Witt wrote: > But some cases I’d like to point out: > > InsetMathSpace::doDispatch() calls createInsetMath_fromDialogStr() > createInsetMath_fromDialogStr calls mathed_parse_cell() > mathed_parse_cell() calls Parser() with NULL buffer > > Similar is the call to createInsetMath_fromDialogStr in > InsetMathRef::doDispatch() and InsetMathRef::changeTarget(). > > These look dangerous too, IMO. What do you think? > Do you know how to trigger this pieces of code? It is hard to tell how dangerous they are. As said, in most cases the validity of the buffer member is checked before being used. So, having a null there is not troublesome for most code paths. However, it can bite in certain cases. In the case at hand, the buffer has always been null but, not being used in certain code paths, it has never been a problem. -- Enrico -- lyx-devel mailing list [email protected] http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bug in Lyx 1.3.4 ?
Am 06.02.2020 um 19:10 schrieb Enrico Forestieri : > > On Thu, Feb 06, 2020 at 06:37:43PM +0100, Stephan Witt wrote: >> Am 06.02.2020 um 15:58 schrieb Enrico Forestieri : >>> >>> On Thu, Feb 06, 2020 at 01:52:15PM +0100, Pavel Sanda wrote: On Thu, Feb 06, 2020 at 08:15:45AM +0100, Stephan Witt wrote: > Am 06.02.2020 um 01:02 schrieb Richard Kimberly Heck : >> >> I assume this is an old bug? Or is it a new one? > > I can reproduce something similar with 2.4.0 too. But I cannot reproduce > with 2.2.4. I can confirm it with Qt5 now. Bisect leads to: commit a2d181905a95b3bb983dac60f3d9603413a01f34 Author: Enrico Forestieri Date: Tue Jun 25 22:23:51 2019 +0200 Fix bug #11586 Do not replace a latex command with the corresponding symbol in the unicodesymbols file unless it can be encoded in the document encoding. >>> >>> That commit simply exposes the bug, which is the fact that the buffer >>> member is not initialized. I think the patch by Stephan is correct. >> >> That leads me to the question if there are more occurrences of this problem. >> >> E.g. with 2.3.x in InsetMathMacro::attachArguments() the line >> >> d->expanded_ = MathData(); >> >> could be better >> >> d->expanded_ = MathData(d->definition_.buffer()); >> >> But in fact I don’t know if it is that simple pattern. > > Uninitialized buffer members have been a plague in mathed in the past. > You will see a lot of code like "buf && buf->something" to account for that. > Sometimes not having a properly initialized buffer member can be > irrelevant and sometimes not. > > Nowadays I think it was spent some effort for properly initializing > (and also updating when copy/pasting) the buffer pointer, so it makes > sense to discover those (now presumably) corner cases and act on them, > rather than adding the check for a null member. > > However, I would act only when we are sure it is an issue, rather than > indiscriminately trying to initialize everything. In the particular > case you report it may be that this initialization is performed later > (note that I did not check, so I cannot be sure). > > I would follow the old "if it ain't broke, don't fix it" approach. I see, thanks for the answer. But some cases I’d like to point out: InsetMathSpace::doDispatch() calls createInsetMath_fromDialogStr() createInsetMath_fromDialogStr calls mathed_parse_cell() mathed_parse_cell() calls Parser() with NULL buffer Similar is the call to createInsetMath_fromDialogStr in InsetMathRef::doDispatch() and InsetMathRef::changeTarget(). These look dangerous too, IMO. What do you think? Do you know how to trigger this pieces of code? Stephan -- lyx-devel mailing list [email protected] http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bug in Lyx 1.3.4 ?
On 2/6/20 2:46 PM, Enrico Forestieri wrote: > On Thu, Feb 06, 2020 at 01:53:34PM -0500, Richard Kimberly Heck wrote: >> On 2/6/20 9:58 AM, Enrico Forestieri wrote: >>> On Thu, Feb 06, 2020 at 01:52:15PM +0100, Pavel Sanda wrote: On Thu, Feb 06, 2020 at 08:15:45AM +0100, Stephan Witt wrote: > Am 06.02.2020 um 01:02 schrieb Richard Kimberly Heck : >> I assume this is an old bug? Or is it a new one? > I can reproduce something similar with 2.4.0 too. But I cannot reproduce > with 2.2.4. I can confirm it with Qt5 now. Bisect leads to: commit a2d181905a95b3bb983dac60f3d9603413a01f34 Author: Enrico Forestieri Date: Tue Jun 25 22:23:51 2019 +0200 Fix bug #11586 Do not replace a latex command with the corresponding symbol in the unicodesymbols file unless it can be encoded in the document encoding. >>> That commit simply exposes the bug, which is the fact that the buffer >>> member is not initialized. I think the patch by Stephan is correct. >> Does this warrant an emergency release? > I would say so. The program cannot crash simply because a toolbar is > used. I am surprised that it did not show up earlier, though. My thinking, too. If someone can commit the fix, I'll produce new tarballs this weekend and we can aim for an emergency release early next week. Riki -- lyx-devel mailing list [email protected] http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bug in Lyx 1.3.4 ?
On Thu, Feb 06, 2020 at 01:53:34PM -0500, Richard Kimberly Heck wrote: > On 2/6/20 9:58 AM, Enrico Forestieri wrote: > > On Thu, Feb 06, 2020 at 01:52:15PM +0100, Pavel Sanda wrote: > >> On Thu, Feb 06, 2020 at 08:15:45AM +0100, Stephan Witt wrote: > >>> Am 06.02.2020 um 01:02 schrieb Richard Kimberly Heck : > I assume this is an old bug? Or is it a new one? > >>> I can reproduce something similar with 2.4.0 too. But I cannot reproduce > >>> with 2.2.4. > >> I can confirm it with Qt5 now. > >> Bisect leads to: > >> > >> commit a2d181905a95b3bb983dac60f3d9603413a01f34 > >> Author: Enrico Forestieri > >> Date: Tue Jun 25 22:23:51 2019 +0200 > >> > >> Fix bug #11586 > >> > >> Do not replace a latex command with the corresponding symbol > >> in the unicodesymbols file unless it can be encoded in the > >> document encoding. > > That commit simply exposes the bug, which is the fact that the buffer > > member is not initialized. I think the patch by Stephan is correct. > > Does this warrant an emergency release? I would say so. The program cannot crash simply because a toolbar is used. I am surprised that it did not show up earlier, though. -- Enrico -- lyx-devel mailing list [email protected] http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bug in Lyx 1.3.4 ?
On 2/6/20 9:58 AM, Enrico Forestieri wrote: > On Thu, Feb 06, 2020 at 01:52:15PM +0100, Pavel Sanda wrote: >> On Thu, Feb 06, 2020 at 08:15:45AM +0100, Stephan Witt wrote: >>> Am 06.02.2020 um 01:02 schrieb Richard Kimberly Heck : I assume this is an old bug? Or is it a new one? >>> I can reproduce something similar with 2.4.0 too. But I cannot reproduce >>> with 2.2.4. >> I can confirm it with Qt5 now. >> Bisect leads to: >> >> commit a2d181905a95b3bb983dac60f3d9603413a01f34 >> Author: Enrico Forestieri >> Date: Tue Jun 25 22:23:51 2019 +0200 >> >> Fix bug #11586 >> >> Do not replace a latex command with the corresponding symbol >> in the unicodesymbols file unless it can be encoded in the >> document encoding. > That commit simply exposes the bug, which is the fact that the buffer > member is not initialized. I think the patch by Stephan is correct. Does this warrant an emergency release? We also have a nasty problem on Windows. That is https://www.lyx.org/trac/ticket/11728 So I'm planning to do something for Windows, at least. Riki -- lyx-devel mailing list [email protected] http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bug in Lyx 1.3.4 ?
On Thu, Feb 06, 2020 at 06:37:43PM +0100, Stephan Witt wrote: > Am 06.02.2020 um 15:58 schrieb Enrico Forestieri : > > > > On Thu, Feb 06, 2020 at 01:52:15PM +0100, Pavel Sanda wrote: > >> On Thu, Feb 06, 2020 at 08:15:45AM +0100, Stephan Witt wrote: > >>> Am 06.02.2020 um 01:02 schrieb Richard Kimberly Heck : > > I assume this is an old bug? Or is it a new one? > >>> > >>> I can reproduce something similar with 2.4.0 too. But I cannot reproduce > >>> with 2.2.4. > >> > >> I can confirm it with Qt5 now. > >> Bisect leads to: > >> > >> commit a2d181905a95b3bb983dac60f3d9603413a01f34 > >> Author: Enrico Forestieri > >> Date: Tue Jun 25 22:23:51 2019 +0200 > >> > >>Fix bug #11586 > >> > >>Do not replace a latex command with the corresponding symbol > >>in the unicodesymbols file unless it can be encoded in the > >>document encoding. > > > > That commit simply exposes the bug, which is the fact that the buffer > > member is not initialized. I think the patch by Stephan is correct. > > That leads me to the question if there are more occurrences of this problem. > > E.g. with 2.3.x in InsetMathMacro::attachArguments() the line > > d->expanded_ = MathData(); > > could be better > > d->expanded_ = MathData(d->definition_.buffer()); > > But in fact I don’t know if it is that simple pattern. Uninitialized buffer members have been a plague in mathed in the past. You will see a lot of code like "buf && buf->something" to account for that. Sometimes not having a properly initialized buffer member can be irrelevant and sometimes not. Nowadays I think it was spent some effort for properly initializing (and also updating when copy/pasting) the buffer pointer, so it makes sense to discover those (now presumably) corner cases and act on them, rather than adding the check for a null member. However, I would act only when we are sure it is an issue, rather than indiscriminately trying to initialize everything. In the particular case you report it may be that this initialization is performed later (note that I did not check, so I cannot be sure). I would follow the old "if it ain't broke, don't fix it" approach. -- Enrico -- lyx-devel mailing list [email protected] http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bug in Lyx 1.3.4 ?
Am 06.02.2020 um 15:58 schrieb Enrico Forestieri : > > On Thu, Feb 06, 2020 at 01:52:15PM +0100, Pavel Sanda wrote: >> On Thu, Feb 06, 2020 at 08:15:45AM +0100, Stephan Witt wrote: >>> Am 06.02.2020 um 01:02 schrieb Richard Kimberly Heck : I assume this is an old bug? Or is it a new one? >>> >>> I can reproduce something similar with 2.4.0 too. But I cannot reproduce >>> with 2.2.4. >> >> I can confirm it with Qt5 now. >> Bisect leads to: >> >> commit a2d181905a95b3bb983dac60f3d9603413a01f34 >> Author: Enrico Forestieri >> Date: Tue Jun 25 22:23:51 2019 +0200 >> >>Fix bug #11586 >> >>Do not replace a latex command with the corresponding symbol >>in the unicodesymbols file unless it can be encoded in the >>document encoding. > > That commit simply exposes the bug, which is the fact that the buffer > member is not initialized. I think the patch by Stephan is correct. That leads me to the question if there are more occurrences of this problem. E.g. with 2.3.x in InsetMathMacro::attachArguments() the line d->expanded_ = MathData(); could be better d->expanded_ = MathData(d->definition_.buffer()); But in fact I don’t know if it is that simple pattern. Stephan -- lyx-devel mailing list [email protected] http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bug in Lyx 1.3.4 ?
On Thu, Feb 06, 2020 at 01:52:15PM +0100, Pavel Sanda wrote: > On Thu, Feb 06, 2020 at 08:15:45AM +0100, Stephan Witt wrote: > > Am 06.02.2020 um 01:02 schrieb Richard Kimberly Heck : > > > > > > I assume this is an old bug? Or is it a new one? > > > > I can reproduce something similar with 2.4.0 too. But I cannot reproduce > > with 2.2.4. > > I can confirm it with Qt5 now. > Bisect leads to: > > commit a2d181905a95b3bb983dac60f3d9603413a01f34 > Author: Enrico Forestieri > Date: Tue Jun 25 22:23:51 2019 +0200 > > Fix bug #11586 > > Do not replace a latex command with the corresponding symbol > in the unicodesymbols file unless it can be encoded in the > document encoding. That commit simply exposes the bug, which is the fact that the buffer member is not initialized. I think the patch by Stephan is correct. -- Enrico -- lyx-devel mailing list [email protected] http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bug in Lyx 1.3.4 ?
On Thu, Feb 06, 2020 at 08:15:45AM +0100, Stephan Witt wrote: > Am 06.02.2020 um 01:02 schrieb Richard Kimberly Heck : > > > > I assume this is an old bug? Or is it a new one? > > I can reproduce something similar with 2.4.0 too. But I cannot reproduce with > 2.2.4. I can confirm it with Qt5 now. Bisect leads to: commit a2d181905a95b3bb983dac60f3d9603413a01f34 Author: Enrico Forestieri Date: Tue Jun 25 22:23:51 2019 +0200 Fix bug #11586 Do not replace a latex command with the corresponding symbol in the unicodesymbols file unless it can be encoded in the document encoding. Pavel -- lyx-devel mailing list [email protected] http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bug in Lyx 1.3.4 ?
Am 06.02.2020 um 01:02 schrieb Richard Kimberly Heck :
>
> I assume this is an old bug? Or is it a new one?
I can reproduce something similar with 2.4.0 too. But I cannot reproduce with
2.2.4.
So it’s rather new.
Stephan
>
> On 2/5/20 6:49 PM, Stephan Witt wrote:
>> Am 06.02.2020 um 00:18 schrieb Stephan Witt
>> :
>>
Am 05.02.2020 um 23:33 schrieb emile lunardon
:
I have installed LyX 2.3.4 on Windows10 and the same crash already seen on
LyX for Linux occurs when trying to enter the two Math Symbols :
$\textrm{Ø}\textrm{Å}$
Le mer. 5 févr. 2020 à 08:32, emile lunardon
a écrit :
When I try to enter, under LyX 1.3.4 (Linux), one of the two Math symbols
shown in the attached file (written with LyX 1.3.3), there is a crash of
LyX 1.3.4 with the attached messages.
Can someone confirm this strange phenomena ?
>>> I can confirm your bug with Qt5 on macOS with LyX 2.3.4. I think this is
>>> the version you’re talking about all the time.
>>>
>>> One has to use the math toolbar and there choose the symbol Å from the
>>> miscellaneous pane.
>>>
>>> The backtrace is:
>>>
>>> (lldb) bt
>>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
>>> (code=1, address=0x18)
>>>frame #0: 0x0001000699dc
>>> LyX`lyx::Buffer::params(this=0x) at Buffer.cpp:719:9
>>>frame #1: 0x00010079fa18 LyX`lyx::(anonymous
>>> namespace)::Parser::parse1(this=0x7ffeefbf5b20,
>>> grid=0x7ffeefbf23e0, flags=128, mode=TEXT_MODE, numbered=false) at
>>> MathParser.cpp:2080:20
>>> * frame #2: 0x000100790987 LyX`lyx::(anonymous
>>> namespace)::Parser::parse(this=0x7ffeefbf5b20,
>>> array=0x000113353690, flags=64, mode=TEXT_MODE) at MathParser.cpp:782:2
>>>frame #3: 0x00010079f18c LyX`lyx::(anonymous
>>> namespace)::Parser::parse1(this=0x7ffeefbf5b20,
>>> grid=0x7ffeefbf5a30, flags=0, mode=MATH_MODE, numbered=false) at
>>> MathParser.cpp:2013:6
>>>frame #4: 0x000100790987 LyX`lyx::(anonymous
>>> namespace)::Parser::parse(this=0x7ffeefbf5b20,
>>> array=0x7ffeefbf6530, flags=0, mode=MATH_MODE) at MathParser.cpp:782:2
>>>frame #5: 0x000100790874
>>> LyX`lyx::mathed_parse_cell(ar=0x7ffeefbf6530, str=L"\\textrm \\AA",
>>> f=NORMAL) at MathParser.cpp:2156:37
>>>frame #6: 0x0001007c28d2 LyX`lyx::asArray(str=L"\\textrm \\AA",
>>> ar=0x7ffeefbf6530, pf=NORMAL) at MathSupport.cpp:990:38
>>>frame #7: 0x0001006deba4
>>> LyX`lyx::InsetMathNest::doDispatch(this=0x0001112cde10,
>>> cur=0x000106149098, cmd=0x7ffeefbf9068) at InsetMathNest.cpp:1237:4
>>>frame #8: 0x00010065baa2
>>> LyX`lyx::InsetMathGrid::doDispatch(this=0x0001112cde10,
>>> cur=0x000106149098, cmd=0x7ffeefbf9068) at InsetMathGrid.cpp:1733:18
>>>frame #9: 0x00010067e615
>>> LyX`lyx::InsetMathHull::doDispatch(this=0x0001112cde10,
>>> cur=0x000106149098, cmd=0x7ffeefbf9068) at InsetMathHull.cpp:2024:18
>>>frame #10: 0x000100811520
>>> LyX`lyx::Inset::dispatch(this=0x0001112cde10, cur=0x000106149098,
>>> cmd=0x7ffeefbf9068) at Inset.cpp:325:2
>>>frame #11: 0x0001001e018b
>>> LyX`lyx::Cursor::dispatch(this=0x000106149098, cmd0=0x00011123dd68)
>>> at Cursor.cpp:337:11
>>>frame #12: 0x000100d876b4
>>> LyX`lyx::frontend::GuiView::dispatchToBufferView(this=0x00011159b6f0,
>>> cmd=0x00011123dd68, dr=0x7ffeefbfc7a0) at GuiView.cpp:3687:15
>>>frame #13: 0x000100d80df6
>>> LyX`lyx::frontend::GuiView::dispatch(this=0x00011159b6f0,
>>> cmd=0x00011123dd68, dr=0x7ffeefbfc7a0) at GuiView.cpp:4343:4
>>>frame #14: 0x000100a96008
>>> LyX`lyx::frontend::GuiApplication::dispatch(this=0x000105d0a1d0,
>>> cmd=0x00011123dd68, dr=0x7ffeefbfc7a0) at GuiApplication.cpp:2076:19
>>>frame #15: 0x000100a8ff88
>>> LyX`lyx::frontend::GuiApplication::dispatch(this=0x000105d0a1d0,
>>> cmd=0x00011123dd68) at GuiApplication.cpp:1405:3
>>>frame #16: 0x00010037a4ea
>>> LyX`lyx::dispatch(action=0x00011123dd68) at LyX.cpp:1462:19
>>>frame #17: 0x000100a41c4b
>>> LyX`lyx::frontend::Action::action(this=0x00011334a560) at
>>> Action.cpp:87:2
>>>frame #18: 0x000100a41d51
>>> LyX`lyx::frontend::Action::qt_static_metacall(_o=0x00011334a560,
>>> _c=InvokeMetaMethod, _id=1, _a=0x7ffeefbfc970) at moc_Action.cpp:81:21
>>>frame #19: 0x00010554d63a QtCore`QMetaObject::activate(QObject*,
>>> int, int, void**) + 2298
>>>frame #20: 0x00010474e185
>>> QtWidgets`QAction::activate(QAction::ActionEvent) + 309
>>>frame #21: 0x000104841be3 QtWidgets`QAbstractButtonPrivate::click()
>>> + 147
>>>frame #22: 0x000104842d6c
>>> QtWidgets`QAbstractButton::mouseReleaseEvent(QMouseEvent*) + 268
>>>frame #23: 0x000104939bbf
>>> QtWidgets`QToolButton::m
Re: Bug in Lyx 1.3.4 ?
I assume this is an old bug? Or is it a new one?
On 2/5/20 6:49 PM, Stephan Witt wrote:
> Am 06.02.2020 um 00:18 schrieb Stephan Witt :
>>> Am 05.02.2020 um 23:33 schrieb emile lunardon :
>>>
>>> I have installed LyX 2.3.4 on Windows10 and the same crash already seen on
>>> LyX for Linux occurs when trying to enter the two Math Symbols :
>>> $\textrm{Ø}\textrm{Å}$
>>>
>>> Le mer. 5 févr. 2020 à 08:32, emile lunardon a
>>> écrit :
>>> When I try to enter, under LyX 1.3.4 (Linux), one of the two Math symbols
>>> shown in the attached file (written with LyX 1.3.3), there is a crash of
>>> LyX 1.3.4 with the attached messages.
>>>
>>> Can someone confirm this strange phenomena ?
>> I can confirm your bug with Qt5 on macOS with LyX 2.3.4. I think this is the
>> version you’re talking about all the time.
>>
>> One has to use the math toolbar and there choose the symbol Å from the
>> miscellaneous pane.
>>
>> The backtrace is:
>>
>> (lldb) bt
>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
>> (code=1, address=0x18)
>>frame #0: 0x0001000699dc
>> LyX`lyx::Buffer::params(this=0x) at Buffer.cpp:719:9
>>frame #1: 0x00010079fa18 LyX`lyx::(anonymous
>> namespace)::Parser::parse1(this=0x7ffeefbf5b20, grid=0x7ffeefbf23e0,
>> flags=128, mode=TEXT_MODE, numbered=false) at MathParser.cpp:2080:20
>> * frame #2: 0x000100790987 LyX`lyx::(anonymous
>> namespace)::Parser::parse(this=0x7ffeefbf5b20, array=0x000113353690,
>> flags=64, mode=TEXT_MODE) at MathParser.cpp:782:2
>>frame #3: 0x00010079f18c LyX`lyx::(anonymous
>> namespace)::Parser::parse1(this=0x7ffeefbf5b20, grid=0x7ffeefbf5a30,
>> flags=0, mode=MATH_MODE, numbered=false) at MathParser.cpp:2013:6
>>frame #4: 0x000100790987 LyX`lyx::(anonymous
>> namespace)::Parser::parse(this=0x7ffeefbf5b20, array=0x7ffeefbf6530,
>> flags=0, mode=MATH_MODE) at MathParser.cpp:782:2
>>frame #5: 0x000100790874
>> LyX`lyx::mathed_parse_cell(ar=0x7ffeefbf6530, str=L"\\textrm \\AA",
>> f=NORMAL) at MathParser.cpp:2156:37
>>frame #6: 0x0001007c28d2 LyX`lyx::asArray(str=L"\\textrm \\AA",
>> ar=0x7ffeefbf6530, pf=NORMAL) at MathSupport.cpp:990:38
>>frame #7: 0x0001006deba4
>> LyX`lyx::InsetMathNest::doDispatch(this=0x0001112cde10,
>> cur=0x000106149098, cmd=0x7ffeefbf9068) at InsetMathNest.cpp:1237:4
>>frame #8: 0x00010065baa2
>> LyX`lyx::InsetMathGrid::doDispatch(this=0x0001112cde10,
>> cur=0x000106149098, cmd=0x7ffeefbf9068) at InsetMathGrid.cpp:1733:18
>>frame #9: 0x00010067e615
>> LyX`lyx::InsetMathHull::doDispatch(this=0x0001112cde10,
>> cur=0x000106149098, cmd=0x7ffeefbf9068) at InsetMathHull.cpp:2024:18
>>frame #10: 0x000100811520
>> LyX`lyx::Inset::dispatch(this=0x0001112cde10, cur=0x000106149098,
>> cmd=0x7ffeefbf9068) at Inset.cpp:325:2
>>frame #11: 0x0001001e018b
>> LyX`lyx::Cursor::dispatch(this=0x000106149098, cmd0=0x00011123dd68)
>> at Cursor.cpp:337:11
>>frame #12: 0x000100d876b4
>> LyX`lyx::frontend::GuiView::dispatchToBufferView(this=0x00011159b6f0,
>> cmd=0x00011123dd68, dr=0x7ffeefbfc7a0) at GuiView.cpp:3687:15
>>frame #13: 0x000100d80df6
>> LyX`lyx::frontend::GuiView::dispatch(this=0x00011159b6f0,
>> cmd=0x00011123dd68, dr=0x7ffeefbfc7a0) at GuiView.cpp:4343:4
>>frame #14: 0x000100a96008
>> LyX`lyx::frontend::GuiApplication::dispatch(this=0x000105d0a1d0,
>> cmd=0x00011123dd68, dr=0x7ffeefbfc7a0) at GuiApplication.cpp:2076:19
>>frame #15: 0x000100a8ff88
>> LyX`lyx::frontend::GuiApplication::dispatch(this=0x000105d0a1d0,
>> cmd=0x00011123dd68) at GuiApplication.cpp:1405:3
>>frame #16: 0x00010037a4ea
>> LyX`lyx::dispatch(action=0x00011123dd68) at LyX.cpp:1462:19
>>frame #17: 0x000100a41c4b
>> LyX`lyx::frontend::Action::action(this=0x00011334a560) at Action.cpp:87:2
>>frame #18: 0x000100a41d51
>> LyX`lyx::frontend::Action::qt_static_metacall(_o=0x00011334a560,
>> _c=InvokeMetaMethod, _id=1, _a=0x7ffeefbfc970) at moc_Action.cpp:81:21
>>frame #19: 0x00010554d63a QtCore`QMetaObject::activate(QObject*, int,
>> int, void**) + 2298
>>frame #20: 0x00010474e185
>> QtWidgets`QAction::activate(QAction::ActionEvent) + 309
>>frame #21: 0x000104841be3 QtWidgets`QAbstractButtonPrivate::click() +
>> 147
>>frame #22: 0x000104842d6c
>> QtWidgets`QAbstractButton::mouseReleaseEvent(QMouseEvent*) + 268
>>frame #23: 0x000104939bbf
>> QtWidgets`QToolButton::mouseReleaseEvent(QMouseEvent*) + 15
>>frame #24: 0x0001047931d2 QtWidgets`QWidget::event(QEvent*) + 450
>>frame #25: 0x00010493a14f QtWidgets`QToolButton::event(QEvent*) + 319
>>frame #26: 0x0001047576ff
>> QtWidgets`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 271
>>frame #2
Re: Bug in Lyx 1.3.4 ?
Am 06.02.2020 um 00:18 schrieb Stephan Witt :
>
>> Am 05.02.2020 um 23:33 schrieb emile lunardon :
>>
>> I have installed LyX 2.3.4 on Windows10 and the same crash already seen on
>> LyX for Linux occurs when trying to enter the two Math Symbols :
>> $\textrm{Ø}\textrm{Å}$
>>
>> Le mer. 5 févr. 2020 à 08:32, emile lunardon a
>> écrit :
>> When I try to enter, under LyX 1.3.4 (Linux), one of the two Math symbols
>> shown in the attached file (written with LyX 1.3.3), there is a crash of LyX
>> 1.3.4 with the attached messages.
>>
>> Can someone confirm this strange phenomena ?
>
> I can confirm your bug with Qt5 on macOS with LyX 2.3.4. I think this is the
> version you’re talking about all the time.
>
> One has to use the math toolbar and there choose the symbol Å from the
> miscellaneous pane.
>
> The backtrace is:
>
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
> (code=1, address=0x18)
>frame #0: 0x0001000699dc
> LyX`lyx::Buffer::params(this=0x) at Buffer.cpp:719:9
>frame #1: 0x00010079fa18 LyX`lyx::(anonymous
> namespace)::Parser::parse1(this=0x7ffeefbf5b20, grid=0x7ffeefbf23e0,
> flags=128, mode=TEXT_MODE, numbered=false) at MathParser.cpp:2080:20
> * frame #2: 0x000100790987 LyX`lyx::(anonymous
> namespace)::Parser::parse(this=0x7ffeefbf5b20, array=0x000113353690,
> flags=64, mode=TEXT_MODE) at MathParser.cpp:782:2
>frame #3: 0x00010079f18c LyX`lyx::(anonymous
> namespace)::Parser::parse1(this=0x7ffeefbf5b20, grid=0x7ffeefbf5a30,
> flags=0, mode=MATH_MODE, numbered=false) at MathParser.cpp:2013:6
>frame #4: 0x000100790987 LyX`lyx::(anonymous
> namespace)::Parser::parse(this=0x7ffeefbf5b20, array=0x7ffeefbf6530,
> flags=0, mode=MATH_MODE) at MathParser.cpp:782:2
>frame #5: 0x000100790874
> LyX`lyx::mathed_parse_cell(ar=0x7ffeefbf6530, str=L"\\textrm \\AA",
> f=NORMAL) at MathParser.cpp:2156:37
>frame #6: 0x0001007c28d2 LyX`lyx::asArray(str=L"\\textrm \\AA",
> ar=0x7ffeefbf6530, pf=NORMAL) at MathSupport.cpp:990:38
>frame #7: 0x0001006deba4
> LyX`lyx::InsetMathNest::doDispatch(this=0x0001112cde10,
> cur=0x000106149098, cmd=0x7ffeefbf9068) at InsetMathNest.cpp:1237:4
>frame #8: 0x00010065baa2
> LyX`lyx::InsetMathGrid::doDispatch(this=0x0001112cde10,
> cur=0x000106149098, cmd=0x7ffeefbf9068) at InsetMathGrid.cpp:1733:18
>frame #9: 0x00010067e615
> LyX`lyx::InsetMathHull::doDispatch(this=0x0001112cde10,
> cur=0x000106149098, cmd=0x7ffeefbf9068) at InsetMathHull.cpp:2024:18
>frame #10: 0x000100811520
> LyX`lyx::Inset::dispatch(this=0x0001112cde10, cur=0x000106149098,
> cmd=0x7ffeefbf9068) at Inset.cpp:325:2
>frame #11: 0x0001001e018b
> LyX`lyx::Cursor::dispatch(this=0x000106149098, cmd0=0x00011123dd68)
> at Cursor.cpp:337:11
>frame #12: 0x000100d876b4
> LyX`lyx::frontend::GuiView::dispatchToBufferView(this=0x00011159b6f0,
> cmd=0x00011123dd68, dr=0x7ffeefbfc7a0) at GuiView.cpp:3687:15
>frame #13: 0x000100d80df6
> LyX`lyx::frontend::GuiView::dispatch(this=0x00011159b6f0,
> cmd=0x00011123dd68, dr=0x7ffeefbfc7a0) at GuiView.cpp:4343:4
>frame #14: 0x000100a96008
> LyX`lyx::frontend::GuiApplication::dispatch(this=0x000105d0a1d0,
> cmd=0x00011123dd68, dr=0x7ffeefbfc7a0) at GuiApplication.cpp:2076:19
>frame #15: 0x000100a8ff88
> LyX`lyx::frontend::GuiApplication::dispatch(this=0x000105d0a1d0,
> cmd=0x00011123dd68) at GuiApplication.cpp:1405:3
>frame #16: 0x00010037a4ea LyX`lyx::dispatch(action=0x00011123dd68)
> at LyX.cpp:1462:19
>frame #17: 0x000100a41c4b
> LyX`lyx::frontend::Action::action(this=0x00011334a560) at Action.cpp:87:2
>frame #18: 0x000100a41d51
> LyX`lyx::frontend::Action::qt_static_metacall(_o=0x00011334a560,
> _c=InvokeMetaMethod, _id=1, _a=0x7ffeefbfc970) at moc_Action.cpp:81:21
>frame #19: 0x00010554d63a QtCore`QMetaObject::activate(QObject*, int,
> int, void**) + 2298
>frame #20: 0x00010474e185
> QtWidgets`QAction::activate(QAction::ActionEvent) + 309
>frame #21: 0x000104841be3 QtWidgets`QAbstractButtonPrivate::click() +
> 147
>frame #22: 0x000104842d6c
> QtWidgets`QAbstractButton::mouseReleaseEvent(QMouseEvent*) + 268
>frame #23: 0x000104939bbf
> QtWidgets`QToolButton::mouseReleaseEvent(QMouseEvent*) + 15
>frame #24: 0x0001047931d2 QtWidgets`QWidget::event(QEvent*) + 450
>frame #25: 0x00010493a14f QtWidgets`QToolButton::event(QEvent*) + 319
>frame #26: 0x0001047576ff
> QtWidgets`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 271
>frame #27: 0x00010475a59d QtWidgets`QApplication::notify(QObject*,
> QEvent*) + 7373
>frame #28: 0x000100a9d033
> LyX`lyx::frontend::GuiApplication::notify(this=0x000
Re: Bug in Lyx 1.3.4 ?
> Am 05.02.2020 um 23:33 schrieb emile lunardon :
>
> I have installed LyX 2.3.4 on Windows10 and the same crash already seen on
> LyX for Linux occurs when trying to enter the two Math Symbols :
> $\textrm{Ø}\textrm{Å}$
>
> Le mer. 5 févr. 2020 à 08:32, emile lunardon a
> écrit :
> When I try to enter, under LyX 1.3.4 (Linux), one of the two Math symbols
> shown in the attached file (written with LyX 1.3.3), there is a crash of LyX
> 1.3.4 with the attached messages.
>
> Can someone confirm this strange phenomena ?
I can confirm your bug with Qt5 on macOS with LyX 2.3.4. I think this is the
version you’re talking about all the time.
One has to use the math toolbar and there choose the symbol Å from the
miscellaneous pane.
The backtrace is:
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x18)
frame #0: 0x0001000699dc
LyX`lyx::Buffer::params(this=0x) at Buffer.cpp:719:9
frame #1: 0x00010079fa18 LyX`lyx::(anonymous
namespace)::Parser::parse1(this=0x7ffeefbf5b20, grid=0x7ffeefbf23e0,
flags=128, mode=TEXT_MODE, numbered=false) at MathParser.cpp:2080:20
* frame #2: 0x000100790987 LyX`lyx::(anonymous
namespace)::Parser::parse(this=0x7ffeefbf5b20, array=0x000113353690,
flags=64, mode=TEXT_MODE) at MathParser.cpp:782:2
frame #3: 0x00010079f18c LyX`lyx::(anonymous
namespace)::Parser::parse1(this=0x7ffeefbf5b20, grid=0x7ffeefbf5a30,
flags=0, mode=MATH_MODE, numbered=false) at MathParser.cpp:2013:6
frame #4: 0x000100790987 LyX`lyx::(anonymous
namespace)::Parser::parse(this=0x7ffeefbf5b20, array=0x7ffeefbf6530,
flags=0, mode=MATH_MODE) at MathParser.cpp:782:2
frame #5: 0x000100790874
LyX`lyx::mathed_parse_cell(ar=0x7ffeefbf6530, str=L"\\textrm \\AA",
f=NORMAL) at MathParser.cpp:2156:37
frame #6: 0x0001007c28d2 LyX`lyx::asArray(str=L"\\textrm \\AA",
ar=0x7ffeefbf6530, pf=NORMAL) at MathSupport.cpp:990:38
frame #7: 0x0001006deba4
LyX`lyx::InsetMathNest::doDispatch(this=0x0001112cde10,
cur=0x000106149098, cmd=0x7ffeefbf9068) at InsetMathNest.cpp:1237:4
frame #8: 0x00010065baa2
LyX`lyx::InsetMathGrid::doDispatch(this=0x0001112cde10,
cur=0x000106149098, cmd=0x7ffeefbf9068) at InsetMathGrid.cpp:1733:18
frame #9: 0x00010067e615
LyX`lyx::InsetMathHull::doDispatch(this=0x0001112cde10,
cur=0x000106149098, cmd=0x7ffeefbf9068) at InsetMathHull.cpp:2024:18
frame #10: 0x000100811520
LyX`lyx::Inset::dispatch(this=0x0001112cde10, cur=0x000106149098,
cmd=0x7ffeefbf9068) at Inset.cpp:325:2
frame #11: 0x0001001e018b
LyX`lyx::Cursor::dispatch(this=0x000106149098, cmd0=0x00011123dd68) at
Cursor.cpp:337:11
frame #12: 0x000100d876b4
LyX`lyx::frontend::GuiView::dispatchToBufferView(this=0x00011159b6f0,
cmd=0x00011123dd68, dr=0x7ffeefbfc7a0) at GuiView.cpp:3687:15
frame #13: 0x000100d80df6
LyX`lyx::frontend::GuiView::dispatch(this=0x00011159b6f0,
cmd=0x00011123dd68, dr=0x7ffeefbfc7a0) at GuiView.cpp:4343:4
frame #14: 0x000100a96008
LyX`lyx::frontend::GuiApplication::dispatch(this=0x000105d0a1d0,
cmd=0x00011123dd68, dr=0x7ffeefbfc7a0) at GuiApplication.cpp:2076:19
frame #15: 0x000100a8ff88
LyX`lyx::frontend::GuiApplication::dispatch(this=0x000105d0a1d0,
cmd=0x00011123dd68) at GuiApplication.cpp:1405:3
frame #16: 0x00010037a4ea LyX`lyx::dispatch(action=0x00011123dd68)
at LyX.cpp:1462:19
frame #17: 0x000100a41c4b
LyX`lyx::frontend::Action::action(this=0x00011334a560) at Action.cpp:87:2
frame #18: 0x000100a41d51
LyX`lyx::frontend::Action::qt_static_metacall(_o=0x00011334a560,
_c=InvokeMetaMethod, _id=1, _a=0x7ffeefbfc970) at moc_Action.cpp:81:21
frame #19: 0x00010554d63a QtCore`QMetaObject::activate(QObject*, int,
int, void**) + 2298
frame #20: 0x00010474e185
QtWidgets`QAction::activate(QAction::ActionEvent) + 309
frame #21: 0x000104841be3 QtWidgets`QAbstractButtonPrivate::click() +
147
frame #22: 0x000104842d6c
QtWidgets`QAbstractButton::mouseReleaseEvent(QMouseEvent*) + 268
frame #23: 0x000104939bbf
QtWidgets`QToolButton::mouseReleaseEvent(QMouseEvent*) + 15
frame #24: 0x0001047931d2 QtWidgets`QWidget::event(QEvent*) + 450
frame #25: 0x00010493a14f QtWidgets`QToolButton::event(QEvent*) + 319
frame #26: 0x0001047576ff
QtWidgets`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 271
frame #27: 0x00010475a59d QtWidgets`QApplication::notify(QObject*,
QEvent*) + 7373
frame #28: 0x000100a9d033
LyX`lyx::frontend::GuiApplication::notify(this=0x000105d0a1d0,
receiver=0x0001114debf0, event=0x7ffeefbfd060) at
GuiApplication.cpp:2712:24
frame #29: 0x00010551c684
QtCore`QCoreApplication::notifyInternal2(QObject*, QEvent*) +
