Am 13.03.2011 um 22:25 schrieb Vincent van Ravesteijn: > Op 13-3-2011 22:20, Tommaso Cucinotta schreef: >> Il 13/03/2011 21:46, Vincent van Ravesteijn ha scritto: >>> A backtrace would be more useful :S.. >> I know, sorry, but I reduced the problem to a simple test-case: >> >> 1. C-n (new document) >> 2. a b >> 3. [Shift+Left][Shift-left] (select the " b" part, including the leading >> space) >> 4. [Space] >> >> #2 0x000000000063027c in __replacement_assert (this=0x1a053c8, __pos=2) at >> /usr/include/c++/4.4/x86_64-linux-gnu/bits/c++config.h:284 >> #3 std::basic_string<wchar_t, std::char_traits<wchar_t>, >> std::allocator<wchar_t> >::operator[] (this=0x1a053c8, __pos=2) at >> /usr/include/c++/4.4/bits/basic_string.h:743 >> #4 0x000000000061a372 in lyx::Paragraph::isWordSeparator (this=0x1a203e0, >> pos=2) at Paragraph.cpp:2852 >> #5 0x000000000061a4fc in lyx::Paragraph::locateWord (this=0x1a203e0, >> from=@0x7fffffff5ad0, to=@0x7fffffff5ad8, loc=4294967295) at >> Paragraph.cpp:3441 >> #6 0x00000000005300a0 in lyx::DocIterator::locateWord (this=<value >> optimized out>, loc=lyx::WHOLE_WORD) at DocIterator.cpp:201 >> #7 0x0000000000718e5c in lyx::Cursor::checkNewWordPosition (this=0x1a2cd68) >> at Cursor.cpp:563 >> #8 0x0000000000719046 in lyx::Cursor::resetAnchor (this=0x1a2cd68) at >> Cursor.cpp:506 >> #9 0x00000000007190c4 in lyx::Cursor::clearSelection (this=0x168f) at >> Cursor.cpp:1157 >> #10 0x000000000072b72f in lyx::cap::cutSelection (cur=..., doclear=<value >> optimized out>, realcut=<value optimized out>) at CutAndPaste.cpp:786 > > Can you check whether this is fixed by r37899 ? If not, can you try to revert > to r37462. Maybe it's also a regression introduced in r37463.
I don't think r37462 is related. The LyX checkout r37923 (of course including r37899) does not crash with your simple test-case. Tommaso, do you have a clean checkout of r37923 to test it? Stephan
