Am Thu, 14 Jan 2021 04:29:21 -0500 schrieb Richard Kimberly Heck <rikih...@lyx.org>:
> On 1/14/21 4:19 AM, Kornel Benko wrote:
> > Am Thu, 14 Jan 2021 04:15:18 -0500
> > schrieb Richard Kimberly Heck <rikih...@lyx.org>:
> >
> >> On 1/14/21 3:45 AM, Kornel Benko wrote:
> >>> Am Thu, 14 Jan 2021 07:53:16 +0100
> >>> schrieb Jürgen Spitzmüller <sp...@lyx.org>:
> >>>
> >>>> Am Donnerstag, dem 14.01.2021 um 00:58 +0100 schrieb Kornel Benko:
> >>>>> How to reproduce
> >>>>>
> >>>>> 1.) Open lyx file e.g. Additional.lyx
> >>>>> 2.) select AdvFind
> >>>>> 3.) select regexp-mode
> >>>>> 4.) insert any text not in this file
> >>>>> 5.) select search for section
> >>>>> 6.) change to not ignore format
> >>>>> 7.) start search
> >>>>> 8.) cancel the search (with escape)
> >>>>> 9.) clean the regex content and try to insert anything ==> crash
> >>>>>
> >>>>> BTW, lyx2.3 does not crash.
> >>>> Does not crash for me. Can you produce a backtrace?
> >>>>
> >>>> Jürgen
> >>>>
> >>> Yes, attached. Last commit was fcea6c47.
> >> That is even weirder. You're getting an assertion, on the ground that a
> >> TOC is being requested that does not yet exist, and the type is
> >> "tableofcontents", which is supposed always to exist. But maybe that
> >> makes sense if it is the TOC for the F&R Buffer itself that is being
> >> queried: Probably it does not have a TOC at all.
> >>
> >> You might try reverting the problematic commit and see if that helps
> >> (i.e., if master minus that commit asserts). That would at least give us
> >> another data point.
> >>
> >> Oh, I see it! The TocBackend::toc method has two versions: A const one
> >> and a non-const one. Because of the const patch, the const one is being
> >> called, I think. It asserts when the requested TOC does not exist,
> >> whereas the other one just creates it and moves along. Though now I'm
> >> puzzled why I don't get a crash. But that makes me think that this has
> >> just revealed some other bug.
> > Good news :)
>
> OK, the assertion happens for you because this test
>
> master != buffer() && !master->hasGuiDelegate()
>
> passes for you and fails for me. I'm not sure why it would pass, though.
> I'm especially puzzled because the active Buffer at #13 in your
> backtrace is the same as what's reported as master at #8. So the test
> ought to fail.
>
> Riki
>
>
I understood the backtrace so that the crash is _before_ this
master != buffer() && !master->hasGuiDelegate()
statement, namely in TocBackend::updateItem(). (This is one line above)
Kornel
pgpNemlvM2m9k.pgp
Description: Digitale Signatur von OpenPGP
-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
