On 04/28/2018 11:35 AM, Scott Kostyshak wrote: > On Sat, Apr 28, 2018 at 01:58:41PM +0000, Richard Kimberly Heck wrote: >> On 04/28/2018 07:58 AM, Jean-Marc Lasgouttes wrote: >>> Le 28/04/2018 à 02:09, Richard Kimberly Heck a écrit : >>>> I'm not good at reading these things, but I do see several >>>> lyx::InsetInclude::~InsetInclude(), which >>>> would presumably be the inset that's being replaced. So it might be some >>>> kind of double delete >>>> issue? Then again, a lot of the log seems to repeat, and I'm not sure I >>>> understand why. >>> The access to the deleted inset happen when painting rows. To me, it >>> means that the inset has been deleted, but the metrics have not been >>> updated, so that they refer to an old inset that does not exist anymore. >>> >>> The deletion of the inset happens when pasting (the ~InsetInclude >>> backtrace refers to Text3.cpp:1422 at some point. Since this deletion >>> makes the current Row invalid, we may have a problem if a dialog is >>> activated because this might trigger a repaint for which we are not >>> ready. Is this a case where a dialog pops up? >> The backtrace that Scott posted earlier did show such a dialog, I believe. > Yes a dialog is involved. In the times that I cannot reproduce the bug, > I get a dialog immediately after pasting (I think it asks whether I want > to create the default master file, since the default master file does > not exist).
There's some kind of race condition involved, then, it seems to me. But I think the general idea JMarc had must be right. It's just that we only get the unfortunate paint event sometimes. Riki
