Crash when loading my thesis (FC5)

[christopher.shucksmith@…]

Yesterday I upgraded from Fedora Core 4 to Fedora Core 5.

Lyx now crashes consistantly every time I load my thesis .Lyx file. Briefly the
document appears on the screen after loading (first page visibale in viewport)
and then SIGSEGV occurs. There are no problems loading the Documents on the Help
menu.

FC4 was lyx-qt-1.4.0-4.fc4

FC5

lyx.i386 1.4.0-4.fc5 installed
lyx-qt.i386 1.4.0-4.fc5 installed

I had no problems using 1.4.0-4 under FC4, so perhaps the fc5 compilation in
extras is broken - possibly gcc 4.1 problem?

I will attach my LyX file, if anyone is on FC5/rawhide could they try and
reproduce the crash? I can try anything you suggest to help debug.

Best wishes,

Chris

[chris@dhcpfh57 ~]$ lyx
OkCancelPolicy: No transition for input SMI_RESTORE from state INITIAL

lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. Please read the bug-reporting instructions
in Help->Introduction and send us a bug report, if necessary. Thanks !
Bye.
Aborted
[chris@dhcpfh57 ~]$ uname -a
Linux dhcpfh57.bnc.ox.ac.uk 2.6.15-1.2054_FC5smp #1 SMP Tue Mar 14 16:05:46 EST
2006 i686 i686 i386 GNU/Linux

I only have the stripped binary here's a backtrace from gdb:

(gdb) run
Starting program: /usr/bin/lyx-qt
Reading symbols from shared object read from target memory...(no debugging
symbols found)...d one.
Loaded system supplied DSO at 0x3d4000
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1208191312 (LWP 9533)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208191312 (LWP 9533)]
0x084c1757 in QPointArray::~QPointArray$delete ()
(gdb) bt
#0 0x084c1757 in QPointArray::~QPointArray$delete ()
#1 0x084cc5d6 in QPointArray::~QPointArray$delete ()
#2 0x08079882 in ?? ()
#3 0x08079aa0 in ?? ()
#4 0x08079e45 in ?? ()
#5 0x084c2646 in QPointArray::~QPointArray$delete ()
#6 0x084c2bb3 in QPointArray::~QPointArray$delete ()
#7 0x084ce03c in QPointArray::~QPointArray$delete ()
#8 0x084ceea6 in QPointArray::~QPointArray$delete ()
#9 0x08079882 in ?? ()
#10 0x08079aa0 in ?? ()
#11 0x08079e45 in ?? ()
#12 0x0832d184 in std::uninitialized_fill_n_a<char*, unsigned int, char, char> ()
#13 0x07500792 in QObject::event () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#14 0x07498a1b in QApplication::internalNotify () from
/usr/lib/qt-3.3/lib/libqt-mt.so.3
#15 0x0749a059 in QApplication::notify () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#16 0x0748c93c in QEventLoop::activateTimers () from
/usr/lib/qt-3.3/lib/libqt-mt.so.3
#17 0x0744110f in QEventLoop::processEvents () from
/usr/lib/qt-3.3/lib/libqt-mt.so.3
#18 0x074b2135 in QEventLoop::enterLoop () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#19 0x074b1fde in QEventLoop::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#20 0x0749865f in QApplication::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#21 0x0838cca0 in QObject::metaObject ()
#22 0x08156a72 in std::deque<int, std::allocator<int> >::_M_push_back_aux ()
---Type <return> to continue, or q <return> to quit---
#23 0x0815798c in std::deque<int, std::allocator<int> >::_M_push_back_aux ()
#24 0x08062a0a in ?? ()
#25 0x005b07e4 in libc_start_main () from /lib/libc.so.6
#26 0x080628a1 in ?? ()

[christopher.shucksmith@…]

Test case, crashes lyx-qt-1.4.0-3.fc5

[alexl@…]

This has also been reported downstream in the Fedora Extras package from
rawhide/FC-5:

​http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184508

[christopher.shucksmith@…]

I installed lyx-debuginfo from the Extras\Development-debugging reppo.
From what I can see the crash occurs in lyx::graphics::Loader::Impl::statusChanged

[chris@dhcpfh57 ~]$ gdb which lyx-qt
GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".

(gdb) run
Starting program: /usr/bin/lyx-qt
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xc9e000
[Thread debugging using libthread_db enabled]
[New Thread -1208215888 (LWP 11145)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208215888 (LWP 11145)]
call_notification (this=0xbfadeb48, b=@0x8ddc018) at
../../../../boost/boost/detail/shared_count.hpp:124
124 ++use_count_;
(gdb) bt
#0 call_notification (this=0xbfadeb48, b=@0x8ddc018) at
../../../../boost/boost/detail/shared_count.hpp:124
#1 0x08079bbe in boost::signal0<void, boost::last_value<void>, int,
std::less<int>, boost::function<void ()(), std::allocator<void> > >::operator() (

this=0x8ddc018) at ../../boost/boost/signals/signal_template.hpp:335

#2 0x084cc538 in lyx::graphics::Loader::Impl::statusChanged (this=0x8ddbff8) at
GraphicsLoader.C:262
#3 0x084cc5d6 in
boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void,
boost::_mfi::mf0<void, lyx::graphics::Loader::Impl>,
boost::_bi::list1<boost::_bi::value<lyx::graphics::Loader::Impl*> > >,
void>::invoke (function_obj_ptr=

{obj_ptr = 0x8cff360, const_obj_ptr = 0x8cff360, func_ptr = 0x8cff360,

data = "`"}) at ../../boost/boost/bind/mem_fn_template.hpp:45
#4 0x08079882 in boost::function0<void, std::allocator<void> >::operator()
(this=0x8dd00f4) at ../../boost/boost/function/function_template.hpp:581
#5 0x08079aa0 in
boost::operator++<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<void>::caller<boost::function<void
()(), std::allocator<void> > >,
boost::signals::detail::named_slot_map_iterator>,
boost::signals::detail::unusable, boost::single_pass_traversal_tag,
boost::signals::detail::unusable const&, int> (i=@0xbfadec94) at
../../boost/boost/signals/signal_template.hpp:119
#6 0x08079e45 in boost::signal0<void, boost::last_value<void>, int,
std::less<int>, boost::function<void ()(), std::allocator<void> > >::operator() (

this=0x8dd38b0) at ../../boost/boost/last_value.hpp:43

#7 0x084c2646 in lyx::graphics::CacheItem::Impl::setStatus (this=0x8dd3880,
new_status=lyx::s::Converting) at GraphicsCacheItem.C:256
#8 0x084c2bb3 in lyx::graphics::CacheItem::Impl::convertToDisplayFormat
(this=0x8dd3880) at GraphicsCacheItem.C:375
#9 0x084ce03c in lyx::graphics::LoaderQueue::loadNext (this=0x86a5c60) at
LoaderQueue.C:48
#10 0x084ceea6 in
boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void,
boost::_mfi::mf0<void, lyx::graphics::LoaderQueue>,
boost::_bi::list1<boost::_bi::value<lyx::graphics::LoaderQueue*> > >,
void>::invoke (function_obj_ptr=

{obj_ptr = 0x8ccfd68, const_obj_ptr = 0x8ccfd68, func_ptr = 0x8ccfd68,

data = "h"}) at ../../boost/boost/bind/mem_fn_template.hpp:45
#11 0x08079882 in boost::function0<void, std::allocator<void> >::operator()
(this=0x8cd0594) at ../../boost/boost/function/function_template.hpp:581
#12 0x08079aa0 in
boost::operator++<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<void>::caller<boost::function<void
()(), std::allocator<void> > >,
boost::signals::detail::named_slot_map_iterator>,
boost::signals::detail::unusable, boost::single_pass_traversal_tag,
boost::signals::detail::unusable const&, int> (i=@0xbfadef14) at
../../boost/boost/signals/signal_template.hpp:119
#13 0x08079e45 in boost::signal0<void, boost::last_value<void>, int,
std::less<int>, boost::function<void ()(), std::allocator<void> > >::operator() (

this=0x86a5ca8) at ../../boost/boost/last_value.hpp:43

#14 0x0832d184 in Timeout::emit (this=0x86a5ca8) at Timeout.C:51
#15 0x07500792 in QObject::event () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#16 0x07498a1b in QApplication::internalNotify () from
/usr/lib/qt-3.3/lib/libqt-mt.so.3
#17 0x0749a059 in QApplication::notify () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#18 0x0748c93c in QEventLoop::activateTimers () from
/usr/lib/qt-3.3/lib/libqt-mt.so.3
#19 0x0744110f in QEventLoop::processEvents () from
/usr/lib/qt-3.3/lib/libqt-mt.so.3
#20 0x074b2135 in QEventLoop::enterLoop () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#21 0x074b1fde in QEventLoop::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#22 0x0749865f in QApplication::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#23 0x0838cca0 in lyx_gui::start (batch=@0x8c00d2c, files=@0xbfadf440) at
lyx_gui.C:248
#24 0x08156a72 in LyX::priv_exec (this=0x8c00d28, argc=@0xbfadf560,
argv=0xbfadf5e4) at lyx_main.C:280
#25 0x0815798c in LyX::exec (argc=@0xbfadf560, argv=0xbfadf5e4) at lyx_main.C:143
#26 0x08062a0a in main (argc=1, argv=0x4) at main.C:47
#27 0x005b07e4 in libc_start_main () from /lib/libc.so.6
#28 0x080628a1 in _start ()
(gdb) info locals
No locals.
(gdb) up
#1 0x08079bbe in boost::signal0<void, boost::last_value<void>, int,
std::less<int>, boost::function<void ()(), std::allocator<void> > >::operator() (

this=0x8ddc018) at ../../boost/boost/signals/signal_template.hpp:335

335 BOOST_SIGNALS_NAMESPACE::detail::call_notification
notification(this->impl);
(gdb) info locals
notification = {impl = {px = 0x2, pn = {pi_ = 0x4}}}
args = {<No data fields>}
(gdb) up
#2 0x084cc538 in lyx::graphics::Loader::Impl::statusChanged (this=0x8ddbff8) at
GraphicsLoader.C:262
262 signal_();
(gdb) info locals
No locals.
(gdb) up
#3 0x084cc5d6 in
boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void,
boost::_mfi::mf0<void, lyx::graphics::Loader::Impl>,
boost::_bi::list1<boost::_bi::value<lyx::graphics::Loader::Impl*> > >,
void>::invoke (function_obj_ptr=

{obj_ptr = 0x8cff360, const_obj_ptr = 0x8cff360, func_ptr = 0x8cff360,

data = "`"}) at ../../boost/boost/bind/mem_fn_template.hpp:45
45 BOOST_MEM_FN_RETURN (p->*f_)();
(gdb) info locals
No locals.
(gdb)

[christopher.shucksmith@…]

I removed every occurance of "\begin_inset Graphics * \end_inset" from the
test case Lyx source and can now load the document without a crash.

# diff new.lyx old.lyx

\begin_inset Graphics

filename img/cmps03.jpg
lyxscale 50
scale 50
keepAspectRatio

\end_inset

<snip>

I have tried remove the image files at the mentioned path and it crashes eitherway.

The issue reported downstream in the Fedora Extras bugzilla reports a crash when
scrolling the document quickly. I can not repoduce this, once loaded scrolling
does not cause a crash for me. Seperate issue?

Debug trace looks like it walks the document to prepare the lyx preview images.
Theres a state change to (#7) new_status=lyx::s::Converting. Does it shell out
to /usr/bin/convert as I see 'Reconfigure' pickes this up?

boost::_bi::list1<boost::_bi::value<lyx::graphics::Loader::Impl*> > >,
void>::invoke (function_obj_ptr=

{obj_ptr = 0x8cff360, const_obj_ptr = 0x8cff360, func_ptr = 0x8cff360,

data = "`"

invoke, loader ... should 'data' be a command line?

[christopher.shucksmith@…]

Workaround: The FC4 packages work in FC5 :-)
# yum remove lyx
# wget ​ftp://fr.rpmfind.net/linux/fedora/extras/4/i386/lyx-1.4.0-4.fc4.i386.rpm
# wget ​ftp://fr.rpmfind.net/linux/fedora/extras/4/i386/lyx-qt-1.4.0-4.fc4.i386.rpm
# rpm -iv lyx-qt-1.4.0-4.fc4.i386.rpm lyx-1.4.0-4.fc4.i386.rpm

[mvanross@…]

see also bug # 2376 (which also has a backtrace)
A quick work-around is to turn off graphics preview.

I have tried to upgrade 'boost' and rebuild but that turned out too tricky for
me.

[lasgouttes]

Could you try with svn trunk (which uses latest boost)?

[Juergen Spitzmueller]

Actually, I think this is a duplictae of #2376. Please check.

[emmerik@…]

I can confirm this bug (also with my thesis; grr.)

It was working fine on 1.4.0.1 (from memory), the bug happens in 1.4.0.4.

Confirm that turning off graphics preview works around the problem.
I'm also running Fedora Core 5.
My backtrace looks similar to the one uploaded, which in my opinion (I don't
know the LyX source code at all) looks quite different from the one in #2376,
even though the symptoms are similar.

My thesis uses an external .layout file, in case that helps.

[Juergen Spitzmueller]

I think the problem is somewhere in FileMonitor.C or GraphicsCache.C, which
uses boost signals.
There have been compilation issues with gcc-4.1 in these files[1], which have
apparently been resolved, but probably not in the right way?

[1] Cf.
​http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg86593.html
​http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg84393.html

[mvanross@…]

This issue is indeed solved for me in 1.5.0 (on FC5).
1.5.0 should be released soon given the severity of the bug.

[lasgouttes]

We are definitely not going to release 1.5.0 soon. So we have to find a
different solution, but which one?

[bard@…]

Yes - this is the bug I get, but it isnt the graphics
it is the scrolling - it happens on the documentation files
as well. It is very nasty. I mainly use Latex straight up but many of my
students use Lyx and send me their files.

[Juergen Spitzmueller]

* #2652 has been marked as a duplicate of this bug. *

[Juergen Spitzmueller]

* #2376 has been marked as a duplicate of this bug. *

[Juergen Spitzmueller]

What makes the difference between 1.4 and 1.5 so that this bug obviously
vanished in the latter?

[lasgouttes]

update to boost, maybe.

[Juergen Spitzmueller]

If it's something we can backport, it would be great. This is the most severe
remaining bug (if you have to use gcc-4.1).

[lasgouttes]

I really do not know where the actual problem lies. Rex, what is the status
of LyX in fedora now? I tried to find it on the fedora page, but I have no idea
where packages are located on this site...

[mvanross@…]

This bug was solved for me long time ago with Lyx 1.4.1
(using FC5).
Should it not be marked as closed?

[rdieter@…]

RE: comment #19
Bug was closed in Fedora's bugzilla when lyx-1.4.1 was released.

[lasgouttes]

Thanks.