Georg Baum wrote:
> Am Mittwoch, 20. September 2006 21:46 schrieb Peter Kümmel:
>> Georg Baum wrote:
>>>> It crashes by design?
>>> Yes: It tries to do some document stuff even if a read failed. I see it
> too
>>> on linux. I am sure that I did not see it some time ago when I did some
>>> lyx2lyx stuff, probably because of an older compiler.
>> the assert tests the operator[](int pos) access: size()>pos but pos is 0.
>> On the lyx side it is *iterCont_[pos]; which eventually does not
>> produce a crash.
>
> My backtrace is completely different:
> 0 0xffffe410 in __kernel_vsyscall ()
> #1 0xa71fd821 in raise () from /lib/tls/i686/cmov/libc.so.6
> #2 0xa71fefb9 in abort () from /lib/tls/i686/cmov/libc.so.6
> #3 0xa7372639 in __gnu_debug::_Error_formatter::_M_error ()
> from /usr/lib/libstdc++.so.6
> #4 0x0836ae52 in ParIterator::operator-> (this=0xafce18cc)
I think it crashes at the same line of code,
the msvc backtrace is only more detailed:
Paragraph * ParIterator::operator->() const
{
return const_cast<Paragraph*>(&text()->getPar(pit()));
with: getPar(pit_type pit) const { return pars_[pit]; }
with: const_reference operator[](size_type pos) const
{
return *iterCont_[pos];
Have you compiled with optimization enabled? Then the compiler
would eliminate all the other calls, so that the crash happens
in the line mentioned by your backtrace.
Peter
