Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 35729 - lyx fails to start with SIGSEGV
Summary: lyx fails to start with SIGSEGV
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: PPC Linux
: High normal (vote)
Assignee: Text-Markup Team (OBSOLETE)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-12-13 07:51 UTC by Axxackall
Modified: 2003-12-15 06:01 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Axxackall 2003-12-13 07:51:55 UTC
I've been using Lyx for awhile on both PPC and x86 I found that at some pint Lyx stopped work for me after some upgrade. It's not the ebuild is broken -  I've tried to rebuild all previos ebuilds and they do not work either. It just doesn't start failed with SIGSEGV. Recompiling it with QT instead of XForms did not help. Looks like the upgrade of some other library or some CFLAGS scred something up. All other GUI applications work fine.

Reproducible: Always
Steps to Reproduce:
1. emerge lyx
2. lyx

Actual Results:  
LyX: Done!
  
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


Expected Results:  
It is expected that it works.
Comment 1 Mike Gardiner (RETIRED) gentoo-dev 2003-12-13 18:32:59 UTC
need more info here really, please post the output of 'emerge info' for starters. also a backtrace would be helpful, how to do this is probably outlined in the 'bug reporting guidelines' that are mentioned (unless these require you to have LyX running...)
Comment 2 Axxackall 2003-12-13 19:57:30 UTC
I just finished recompiling it with stripped CFLAGS (CFLAGS="" emerge lyx) and now it works fine. That means that "unset CFLAGS" inside the ebuild doesn't work (it doesn't unset). 
Comment 3 Axxackall 2003-12-13 19:58:30 UTC
 # emerge info
Portage 2.0.49-r15 (default-ppc-1.4, gcc-3.2.3, glibc-2.3.2-r3, 2.4.22-ben2)
=================================================================
System uname: 2.4.22-ben2 ppc
Gentoo Base System version 1.4.3.10
distcc 2.9 powerpc-unknown-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
ACCEPT_KEYWORDS="ppc"
AUTOCLEAN="yes"
CFLAGS="-O2 -pipe -mcpu=7400 -maltivec -fsigned-char"
CHOST="powerpc-unknown-linux-gnu"
COMPILER="gcc3"
CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /opt/jakarta/tomcat/conf /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"
CXXFLAGS="-O2 -pipe -mcpu=7400 -maltivec -fsigned-char"
DISTDIR="/usr/portage/distfiles"
FEATURES="ccache sandbox buildpkg"
GENTOO_MIRRORS="http://adelie.polymtl.ca/"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="foomaticdb gnome-libs oss alsa esd sdl oggvorbis xmms -arts mad mpeg dvb xvid matroska faad ladcca jack-caps jack fluidsynth sox slang readline xml xml2 libwww ssl mitshm zlib ncurses berkdb gdbm postgres pgsql postgresql libg++ libgda -odbc innodb mysql pg-hier mdb sqlite gnomedb evo ldap imap maildir snmp zeo crypt encode tcpd pam -afs slp cups pdflib tetex spell -doc -nls scanner gphoto2 pda cdr dvd dvdr gpm perl python tcltk ruby java guile gb X gnome gtk gtk2 gtkhtml truetype bonobo -qt -kde motif opengl jpeg png gif tiff gd aalib xv imlib mozilla mozsvg mozcalendar mozaccess mozinterfaceinfo mozp3p mozxmlterm emacs xemacs xemacs-packages-sumo xface mule leim ppc"
 
Comment 4 Mike Gardiner (RETIRED) gentoo-dev 2003-12-13 20:51:28 UTC
RE: comment #2 - that's not how the logic of the ebuild works. It saves your CFLAGS as a local variable 'flags' and then uses that for the configure (see --enable-optimisation=$flags). 

Therefore it's something in your CFLAGS, but exactly what I'm not sure - I've never had a PPC available for testing. Perhaps try without -fsigned-char for starters, or -maltivec

I'll CC ppc@gentoo.org for more ideas.
Comment 5 Bartosch Pixa (RETIRED) gentoo-dev 2003-12-13 21:42:10 UTC
drop -fsigned-char
Comment 6 Axxackall 2003-12-14 02:35:55 UTC
dropping -fsigned-char or -maltivec is not enough - it still fails.
Comment 7 Bartosch Pixa (RETIRED) gentoo-dev 2003-12-14 03:44:06 UTC
just noticed, when you use -maltivec you should also use -mabi=altivec, so either both or none, the rest of your cflags should be perfectly sane
so probably one of the deps od lyx is either screwed up or incompatible
Comment 8 Axxackall 2003-12-14 10:45:58 UTC
$ gdb lyx
GNU gdb 5.3
Copyright 2002 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 "powerpc-unknown-linux-gnu"...
(no debugging symbols found)...
(gdb) run
Starting program: /usr/bin/lyx
(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)...
Program received signal SIGSEGV, Segmentation fault.
0x10019f04 in std::string& std::string::_M_replace_safe<char const*>(__gnu_cxx::__normal_iterator<char*, std::string>, __gnu_cxx::__normal_iterator<char*, std::string>, char const*, char const*) ()
(gdb) bt
#0  0x10019f04 in std::string& std::string::_M_replace_safe<char const*>(__gnu_cxx::__normal_iterator<char*, std::string>, __gnu_cxx::__normal_iterator<char*, std::string>, char const*, char const*) ()
#1  0x10016560 in std::basic_string<char, std::char_traits<char>, std::allocator<char> > std::operator+<char, std::char_traits<char>, std::allocator<char> >(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#2  0x10211a04 in std::deque<int, std::allocator<int> >::~deque() ()
#3  0x10212004 in std::deque<int, std::allocator<int> >::~deque() ()
#4  0x10210c8c in std::deque<int, std::allocator<int> >::~deque() ()
#5  0x0fede764 in fl_handle_it () from /usr/X11R6/lib/libforms.so.1
#6  0x0fedeb04 in fl_handle_object () from /usr/X11R6/lib/libforms.so.1
#7  0x0fede1dc in redraw_marked () from /usr/X11R6/lib/libforms.so.1
#8  0x0fede400 in fl_redraw_form () from /usr/X11R6/lib/libforms.so.1
#9  0x0feca26c in fl_show_form_window () from /usr/X11R6/lib/libforms.so.1
#10 0x0feca298 in fl_show_form () from /usr/X11R6/lib/libforms.so.1
#11 0x1020ce60 in std::deque<int, std::allocator<int> >::~deque() ()
#12 0x1021885c in std::deque<int, std::allocator<int> >::~deque() ()
#13 0x1008eedc in std::deque<int, std::allocator<int> >::~deque() ()
#14 0x100c2a20 in std::deque<int, std::allocator<int> >::~deque() ()
#15 0x0f9e3e44 in __libc_start_main () from /lib/libc.so.6
(gdb)
#0  0x10019f04 in std::string& std::string::_M_replace_safe<char const*>(__gnu_cxx::__normal_iterator<char*, std::string>, __gnu_cxx::__normal_iterator<char*, std::string>, char const*, char const*) ()
#1  0x10016560 in std::basic_string<char, std::char_traits<char>, std::allocator<char> > std::operator+<char, std::char_traits<char>, std::allocator<char> >(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#2  0x10211a04 in std::deque<int, std::allocator<int> >::~deque() ()
#3  0x10212004 in std::deque<int, std::allocator<int> >::~deque() ()
#4  0x10210c8c in std::deque<int, std::allocator<int> >::~deque() ()
#5  0x0fede764 in fl_handle_it () from /usr/X11R6/lib/libforms.so.1
#6  0x0fedeb04 in fl_handle_object () from /usr/X11R6/lib/libforms.so.1
#7  0x0fede1dc in redraw_marked () from /usr/X11R6/lib/libforms.so.1
#8  0x0fede400 in fl_redraw_form () from /usr/X11R6/lib/libforms.so.1
#9  0x0feca26c in fl_show_form_window () from /usr/X11R6/lib/libforms.so.1
#10 0x0feca298 in fl_show_form () from /usr/X11R6/lib/libforms.so.1
#11 0x1020ce60 in std::deque<int, std::allocator<int> >::~deque() ()
#12 0x1021885c in std::deque<int, std::allocator<int> >::~deque() ()
#13 0x1008eedc in std::deque<int, std::allocator<int> >::~deque() ()
#14 0x100c2a20 in std::deque<int, std::allocator<int> >::~deque() ()
#15 0x0f9e3e44 in __libc_start_main () from /lib/libc.so.6
(gdb) quit
The program is running.  Exit anyway? (y or n) y
Comment 9 Axxackall 2003-12-14 23:56:50 UTC
I've checkes all (perhaps) combinations of cflags and found the bad one: it's -O2.

Even "-O2 -pipe" makes lyx crashing. Degrading it to "-O -pipe" solves the problem.

-fsigned-char doesn't crash lyx. As for -maltivec, yes it crashes lyx when without -mabi=altivec.

So, the beststable result was achived with "-O -pipe -mcpu7400 -maltivec -mabi-altivec -fsigned-char"

By the way, I disagree that it's depends of lyx that were screed up. Otherwise, how does recompiling lyx itself with degraded flag solve the problem?

Question: should ebuild insist to reduce -ON to -O ?
Comment 10 Mike Gardiner (RETIRED) gentoo-dev 2003-12-15 01:20:22 UTC
> Question: should ebuild insist to reduce -ON to -O ?

I really would prefer not to force filtering on every flag. To some extent the CFLAGS are the responsibility of the user, and that's the view I've usually held. This is the first time it has come up as well. But I'm going to ask for two things to help clarify this, from the PPC team.

PPC guys)
o  are these CFLAGS safe and normal in a way that a lot of users would have ?
o  can you reproduce the crashes with these flags ?
Comment 11 Bartosch Pixa (RETIRED) gentoo-dev 2003-12-15 05:29:12 UTC
"-O2 -pipe -mcpu=7400 -maltivec -mabi=altivec" are the recomended default cflags for a G4, so these are safe and -fsigned-char should NOT be used
and no i can't reproduce this, lyx 1.2.1 starts fine over here
Comment 12 Luca Barbato gentoo-dev 2003-12-15 05:37:49 UTC
you should remove -fsigned-char, the app should use it if needed, forcing it will result in unespected behaviour.
Here lyx (qt) is working fine even if built with some (-O2 altivec flags, etc) optimizations.

You may like to rebuild everything w/out -fsigned-char just to have a stable foundation...

Comment 13 Mike Gardiner (RETIRED) gentoo-dev 2003-12-15 06:01:03 UTC
Thanks lu_zero, DarkSpector, it looks to me like a local problem. Please remove -fsigned-char as suggested, but as this is non-reproducable I can't justify filtering flags in the ebuild. Thanks all.