On Wed, Nov 03, 2021 at 05:18:44PM +0100, Jürgen Spitzmüller wrote:
> Am Mittwoch, dem 03.11.2021 um 16:43 +0100 schrieb Pavel Sanda:
> > Well, nothing against this particular patch, but the problem is that
> > if we accept that models_.find(type) might sucesfully return hashes
> > which are actual
Am Mittwoch, dem 03.11.2021 um 16:43 +0100 schrieb Pavel Sanda:
> Well, nothing against this particular patch, but the problem is that
> if we accept that models_.find(type) might sucesfully return hashes
> which are actually bogus, then all other models_.find occurences
> might be in the same dang
On Wed, Nov 03, 2021 at 03:59:25PM +0100, Jürgen Spitzmüller wrote:
> Am Mi., 3. Nov. 2021 um 15:17 Uhr schrieb Pavel Sanda :
>
> > I am afraid unless we want to revamp the whole toc update machinery we just
> > shouldn't by default that expect toc_ is nonempty.
> >
>
> This means that my patch w
Am Mi., 3. Nov. 2021 um 15:17 Uhr schrieb Pavel Sanda :
> I am afraid unless we want to revamp the whole toc update machinery we just
> shouldn't by default that expect toc_ is nonempty.
>
This means that my patch which checks for toc_ emptiness should go in,
right?
Jürgen
>
> Pavel
> --
> lyx
On Tue, Nov 02, 2021 at 10:07:20PM +0100, Pavel Sanda wrote:
> We call various reset() and clear() routines many many times,
> and its unclear to me why we repeatedlt call the whole machinery.
>From what I can see in the code the route to touching toc_ is:
Guiview::structureChanged() ->
Am Mi., 3. Nov. 2021 um 13:42 Uhr schrieb Pavel Sanda :
> I can't reproduce this and do get the crash even when commenting the block
> statements except return.
>
Right. Maybe it didn't crash for me by coincidence.
Jürgen
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/ma
Am Wed, 3 Nov 2021 13:41:37 +0100
schrieb Pavel Sanda :
> On Wed, Nov 03, 2021 at 08:28:59AM +0100, Jürgen Spitzmüller wrote:
> > > Maybe this code (TocWidget::updateView()) is to blame?
> > >
> > > if (!gui_view_.documentBufferView()) {
> > >
> > > tocTV->setModel(nullptr);
> > >
> >
On Wed, Nov 03, 2021 at 08:28:59AM +0100, Jürgen Spitzmüller wrote:
> > Maybe this code (TocWidget::updateView()) is to blame?
> >
> > if (!gui_view_.documentBufferView()) {
> >
> > tocTV->setModel(nullptr);
> >
> > depthSL->setMaximum(0);
> >
> > depthSL->se
Am Mi., 3. Nov. 2021 um 08:14 Uhr schrieb Jürgen Spitzmüller :
> Maybe this code (TocWidget::updateView()) is to blame?
>
> if (!gui_view_.documentBufferView()) {
>
> tocTV->setModel(nullptr);
>
> depthSL->setMaximum(0);
>
> depthSL->setValue(0);
>
>
Am Di., 2. Nov. 2021 um 22:08 Uhr schrieb Pavel Sanda :
> I believe something else is going on.
>
> When you add something like
> +++ b/src/frontends/qt/TocModel.cpp
> @@ -327,6 +330,7 @@ TocItem const TocModels::currentItem(QString const &
> type,
> }
> LASSERT(index.model() == it
On Tue, Nov 02, 2021 at 08:08:05AM +0100, Jürgen Spitzmüller wrote:
> Am Montag, dem 01.11.2021 um 22:51 +0100 schrieb Pavel Sanda:
> > I don't know the code in question either, but I can try to look later
> > this week.
>
> OTOH we test for empty toc_ in several other places of the TocModel, so
>
Am Montag, dem 01.11.2021 um 22:51 +0100 schrieb Pavel Sanda:
> I don't know the code in question either, but I can try to look later
> this week.
OTOH we test for empty toc_ in several other places of the TocModel, so
the check the patch adds might be reasonable (maybe the toc is not yet
re-creat
On Mon, Nov 01, 2021 at 05:01:34PM +0100, Jürgen Spitzmüller wrote:
> Am Montag, dem 01.11.2021 um 14:15 +0100 schrieb Pavel Sanda:
> > Looking at the backtrace and commit it seems that
> > + TocItem const & item =
> > + gui_view_.tocModels().currentItem(current_type_,
> >
Am Montag, dem 01.11.2021 um 14:15 +0100 schrieb Pavel Sanda:
> Looking at the backtrace and commit it seems that
> + TocItem const & item =
> + gui_view_.tocModels().currentItem(current_type_,
> index);
> triggers the crash.
>
> Juergen, can you reproduce?
Yes. I am not
Hi,
I get the crash in majority of cases when using the following recipy:
1. launch lyx & open introduction manual
2. open new window via file -> new window
3. view->hidden->introduction
4. kaboom
/usr/include/c++/10/debug/vector:434:
In function:
std::__debug::vector<_Tp, _Allocator>::const
Le 27/05/2019 à 05:52, Richard Kimberly Heck a écrit :
You get the same crash if you modify (a copy of) Customization.lyx and
then Revert to Saved.
The problem is a stale TOC from before we reloaded the Buffer: When we
get to
submenu.expandTocSubmenu(toc.first, *toc.second);
in Me
Am Sonntag, 26. Mai 2019, 23:52:22 CEST schrieb Richard Kimberly Heck:
> On 5/25/19 9:44 AM, Kornel Benko wrote:
> > 1.) Open lib/doc/Customization.lyx
> > 2.) Save as CustomizationMin.lyx in different directory --> crash
> > The file CustomizationMin.lyx looks OK though.
> >
> > Backtrace:
> > Thr
On 5/25/19 9:44 AM, Kornel Benko wrote:
> 1.) Open lib/doc/Customization.lyx
> 2.) Save as CustomizationMin.lyx in different directory --> crash
> The file CustomizationMin.lyx looks OK though.
>
> Backtrace:
> Thread 1 "lyx2.4" received signal SIGSEGV, Segmentation fault.
> 0x00d9c4b8 in l
On 2019-05-26, Scott Kostyshak wrote:
> [-- Type: text/plain, Encoding: --]
> On Sat, May 25, 2019 at 03:44:02PM +0200, Kornel Benko wrote:
>> 1.) Open lib/doc/Customization.lyx
>> 2.) Save as CustomizationMin.lyx in different directory --> crash
>> The file CustomizationMin.lyx looks OK though.
On Sat, May 25, 2019 at 03:44:02PM +0200, Kornel Benko wrote:
> 1.) Open lib/doc/Customization.lyx
> 2.) Save as CustomizationMin.lyx in different directory --> crash
> The file CustomizationMin.lyx looks OK though.
Just a note to say that I can reproduce.
Scott
signature.asc
Description: PGP s
1.) Open lib/doc/Customization.lyx
2.) Save as CustomizationMin.lyx in different directory --> crash
The file CustomizationMin.lyx looks OK though.
Backtrace:
Thread 1 "lyx2.4" received signal SIGSEGV, Segmentation fault.
0x00d9c4b8 in lyx::CursorSlice::text() const (this=0x2c44160)
at
On Thu, May 23, 2019 at 10:37:47AM +0200, Jean-Marc Lasgouttes wrote:
> Le 23/05/2019 ?? 00:21, Pavel Sanda a écrit :
>> Hi,
>> I have reproducible crash with master & qt 4.8.5.
>> When trying to open Tutorial in Help menu I get:
>>
> Sorry about that. Does it work now?
Seems to be ok now, thanks.
Le 23/05/2019 à 00:21, Pavel Sanda a écrit :
Hi,
I have reproducible crash with master & qt 4.8.5.
When trying to open Tutorial in Help menu I get:
Sorry about that. Does it work now?
JMarc
Am Mittwoch, 22. Mai 2019, 22:24:36 CEST schrieb Richard Kimberly Heck:
> On 5/22/19 6:26 PM, Pavel Sanda wrote:
> > On Thu, May 23, 2019 at 12:21:49AM +0200, Pavel Sanda wrote:
> >> lassert.cpp (51): ASSERTION pos <= par.size() VIOLATED IN
> >> TextMetrics.cpp:1619
> >> ( 1) src/lyx: lyx::doAsse
On 5/22/19 6:26 PM, Pavel Sanda wrote:
> On Thu, May 23, 2019 at 12:21:49AM +0200, Pavel Sanda wrote:
>> lassert.cpp (51): ASSERTION pos <= par.size() VIOLATED IN
>> TextMetrics.cpp:1619
>> ( 1) src/lyx: lyx::doAssertWithCallstack(bool)
>> ( 2) src/lyx: lyx::doAssert(char const*, char const*, lo
On Thu, May 23, 2019 at 12:21:49AM +0200, Pavel Sanda wrote:
> lassert.cpp (51): ASSERTION pos <= par.size() VIOLATED IN TextMetrics.cpp:1619
> ( 1) src/lyx: lyx::doAssertWithCallstack(bool)
> ( 2) src/lyx: lyx::doAssert(char const*, char const*, long)
> ( 3) src/lyx: lyx::TextMetrics::leftMargi
Hi,
I have reproducible crash with master & qt 4.8.5.
When trying to open Tutorial in Help menu I get:
lassert.cpp (51): ASSERTION pos <= par.size() VIOLATED IN TextMetrics.cpp:1619
( 1) src/lyx: lyx::doAssertWithCallstack(bool)
( 2) src/lyx: lyx::doAssert(char const*, char const*, long)
( 3)
27 matches
Mail list logo