Le 30/06/2015 19:20, Enrico Forestieri a écrit :
On Tue, Jun 30, 2015 at 06:14:05PM +0100, Guillaume M-M wrote:Dear list,I got an assertion in stable (1b596e92) for the second time today. It happened while selecting text (first time with Shift+Arrows and second time with the mouse). I don't remember seeing it before: if it wasn't introduced recently then maybe it was hidden by the fact that I did not use instant preview before. I cannot think of anything particular in my settings apart from instant preview on, only one document displayed. I opened gdb after the first crash just in case. I don't know how to reproduce it, the second crash happened when I was no longer paying attention. I am keeping my gdb session open for a while if you would like me to extract more relevant informations than the trace below, just ask. Messages: CursorSlice.cpp (207): can't compare cursor and anchor in different insets p: inset: 0x414e320 idx: 8 par: 4294967295 pos: 7308604897068083558 q: inset: 0x2efa670 idx: 2 par: 4294967295 pos: 12079 lassert.cpp (42): ASSERTION false VIOLATED IN CursorSlice.cpp:209 Assertion triggered in void lyx::doAssert(const char*, const char*, long int) by failing check "false" in file lassert.cpp:44The interesting thread seems to be Thread 4 but it was truncated too early.Thread 4 (Thread 0x7fffde979700 (LWP 27221)): #0 0x00007ffff59e6267 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 #1 0x00007ffff59e7eca in __GI_abort () at abort.c:89 #2 0x000000000059418d in ?? () #3 0x0000000004df8db0 in ?? () #4 0x00000000005139a1 in ?? () #5 0x0a007fffde977c68 in ?? () #6 0x2ede86bc847dcc00 in ?? () #7 0x0000000001d3b608 in ?? () #8 0x0000000000000000 in ?? ()Try running under gdb after setting a breakpoint at CursorSlice.cpp:206 (before the LASSERT line) and take a backtrace when it triggers. I have no idea why it happens and wonder how many bugs are still lurking there when instant preview for math is on... In any case, it would greatly help if you can provide a reproducer. However, note that this does not seem to be a fatal bug and LyX would simply continue running when compiled in release mode.
I found that this behaviour could be associated to segfault with data loss.Here are two reproducers with instructions included. Occurs with stable at 5a550d0a.
The files have "sigsegv" in their names but they actually trigger the above assertion in CursorSlice.cpp. This is because my non-minimal original example produced a segfault instead of asserting. I did not notice that the error message changed while minimizing the file, but if it's really important I can try again and this time preserve the segfault, although I predict that it is going to be complicated because the behaviour is very volatile. (or I could send it privately)
The data loss can be as follows: - in 100% of the cases, the emergency save is corrupted- it is possible that both the emergency save and the save file end up corrupted (if the user saves while LyX is in an incoherent state, as demonstrated in lyx-preview-sigsegv5.lyx)
lyx-preview-sigsegv5.lyx seems a bit complicated, this is because if I removed anything it would crash right at step 3, which is not what I wanted to demonstrate.
lyx-sigsegv-dataloss.lyx
Description: application/lyx
lyx-preview-sigsegv5.lyx
Description: application/lyx
lyx-sigsegv-dataloss-subfile.lyx
Description: application/lyx
