I had no problems with the first release of gnome-shell-3.0.1, but the following release refused to log in, so I pulled back to 2.32 and now 3.2.1 is out there, I thought I would give it a try. I have yet to successfully log in and use gnome-shell-3.2.1 and dmesg shows a general protection error in libmozjs185.so every time. I know this shared object belongs to Spidermonkey-1.8.5 (which is masked). I have recompiled my entire system and depcleaned, and still no luck. The shell does not automatically fall back to gnome-fallback unless I change "eselect opengl set nvidia" to "eselect opengl set xorg-x11" Reproducible: Always Steps to Reproduce: 1.Log in to gnome-shell using GDM or startx 2.Use gnome-shell 3. Actual Results: GDM fades to the desktop, a short pause, then 2 flickers of screen (which looks like the point where the panel is trying to load) followed by the fail whale. Click on log out and taken back to GDM log in again. Expected Results: Should be able to log in to gnome-shell using GDM and use gnome-3.2.1 I have read on the forums about a problem with nvidia-drivers, in particular the stable nvidia-driver-275.09.07, so I have emerged the latest ~x86, which is 285.05.09, but still no luck. (I have a Geforce 8800GT) Likewise with xorg-server. No matter which combination, I still get the same general protection error in libmozjs185.so . I have also tried the nouveau driver and still no joy. I use distcc, and have built gnome-shell, spidermonkey, gjs, gobject etc etc with the FEATURES="-distcc" as I am aware distcc can cause problems. emerge --info Portage 2.1.10.31 (default/linux/x86/10.0/desktop/gnome, gcc-4.5.3, glibc-2.13-r4, 3.0.6-gentoo i686) ================================================================= System uname: Linux-3.0.6-gentoo-i686-Pentium-R-_Dual-Core_CPU_E5400_@_2.70GHz-with-gentoo-2.0.3 Timestamp of tree: Tue, 25 Oct 2011 23:00:01 +0000 distcc 3.1 i686-pc-linux-gnu [enabled] app-shells/bash: 4.2_p8-r1 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.2-r3, 3.1.4-r3, 3.2.2 dev-util/cmake: 2.8.4-r1 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.0.3 sys-apps/openrc: 0.8.3-r1 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1, 9999 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.5, 4.5.3-r1 sys-devel/gcc-config: 1.4.1-r1 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r1 sys-kernel/linux-headers: 2.6.39 (virtual/os-headers) sys-libs/glibc: 2.13-r4 Repositories: gentoo sunrise zugaina desktop-effects gamerlay-stable sardemff7 gnome ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="* -@EULA dlj-1.1 Oracle-BCLA-JavaSE" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=core2 -mmmx -msse -msse2 -msse3 -mmmx -O2 -ggdb -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=core2 -mmmx -msse -msse2 -msse3 -mmmx -O2 -ggdb -pipe -fomit-frame-pointer" DISTDIR="/mnt/nfs_portage/distfiles" FEATURES="assume-digests binpkg-logs distcc distlocks ebuild-locks fixlafiles metadata-transfer news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="" GENTOO_MIRRORS="http://mirror.bytemark.co.uk/gentoo/ http://mirror.qubenet.net/mirror/gentoo/ http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/ http://gentoo.virginmedia.com/" LANG="en_GB.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en_GB" MAKEOPTS="-j7" PKGDIR="/mnt/nfs_portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/mnt/nfs_portage" PORTDIR_OVERLAY="/var/lib/layman/sunrise /var/lib/layman/zugaina /var/lib/layman/desktop-effects /var/lib/layman/gamerlay /var/lib/layman/sardemff7 /var/lib/layman/gnome" SYNC="rsync://pig2/gentoo-portage" USE="X X509 a52 aac acl acpi additions alsa animation-rtl apache2 applet archive artworkextra autoipd berkdb binary-drivers bluetooth branding bzip2 cairo caps cdaudio cdda cdio cdr cdrkit cdrom cdrtools cg cifs cleartype cli client consolekit cracklib crypt cuda cups curl curlwrappers cursors cxx dbase dbus desktop-effects device-mapper dga dns dri dso dts dv dvb dvbplayer dvbsetup dvd dvdnav dvdr dvdread eds effects emboss encode equalizer evo exif extraicons extras fam fat fat16 fbcondecor fbosd fbsplash ffmpeg fftw firefox fits flac flash fltk flv fontconfig foomaticdb fortran ftp fuse gallium games gcj gconf gd gdbm gdm gdu gedit gif git gjs glade glib glitz glx gmedia gnome gnome-dvb-daemon gnome-keyring gnome-print gnome-shell gnomecanvas gnomecd gnutls gphoto2 gpib gpm gps graphviz grub gstreamer gtk gtkhtml gtkstyle h224 hardware hddtemp help-screen hibernate-script hidd howl-compat hpn htsp http httpd i2c icc icons iconv id3 id3tag idn ieee1394 imagemagick imap inotify ipc iplayer iptables ipv6 ivman jack java java6 javascript jpeg jpeg2k kdrive kerberos keymap lame laptop lastfm lastfmradio lcms ldap libburn libgda libmpeg2 libnotify libsamplerate libsexy libsoup libv4l2 libvisual lm_sensors logrotate lzo mad mailwrapper mbox mdnsresponder-compat metadata mime mms mmx mmxext mng modplug modules mono mp2 mp3 mp4 mpd mpeg mpg123 mplayer mudflap nautilus ncurses net network networking networkmanager new-login nfs nfsv3 nfsv4 nls nptl nptlonly nss ntfs ntp nvidia nvram nvtv objc offensive ogg openal opengl openmp openstreetmap optimization osc oss outputs overlays pam parted pcre pdf perl pipechan pixmaps player playlist plugins plymouth pm-utils pmu png policykit ppds pppd pvr pyqt4 python python-daap qt4 quicktime quvi raw readline rss rsync rtsp ruby sasl scrobbler sctp sdl search-screen server session sftp shaders sharedext sharedmem shm shmvideo showtabbar sid sip slideshow slp smi smp smtp sndfile snmp sockets sound spell splash sql sqlite sse sse2 sse3 ssh ssl ssse3 startup-notification svg swf symlink sysfs syslog sysvipc taglib tcpd tdb teletext tetex themes theora tiff tk toolbar tools tordns totem transcode truetype tvheadend twisted twolame type3 udev udev-acl underscores unicode unsupported upnp usb userpriv v4l2 vdpau vdr vfat vga vhook via video videos virtualbox vnc vorbis wav wavpack weather weather-metar weather-xoap webdav win32codecs wma wmf wmp wxwidgets x264 x86 x86emu xattr xcb xcomposite xcursors xf86 xine xml xorg xosd xpm xrandr xrender xulrunner xv xvid xvmc youtube yv12 zlib" ALSA_CARDS="emu10k1 hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="auth_digest authn_file authz_groupfile authz_host dav dav_fs dir mime status" CALLIGRA_FEATURES="kexi words flow plan stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" DRACUT_MODULES="plymouth" DVB_CARDS="usb-wt220u" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_GB" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS
Created attachment 290855 [details] abrt.log using the abrt tool from redhat. When I ran the abrt program, it also pointed out a problem with gnome-settings-daemon, so I have included that info in the file also. This is my first ever bug report, so apologies if I have missed anything.
same for me
(In reply to comment #1) > Created attachment 290855 [details] > abrt.log using the abrt tool from redhat. Since gnome-settings-daemon crashed immediately before gnome-shell, it seems reasonable to suppose that the gnome-settings-daemon crash might have caused gnome-shell to misbehave. First of all, please update to gdm-3.2.1.1-r1; it should now launch gnome-shell and gnome-settings-daemon with a different set of environment variables. Second, rebuild gnome-settings-daemon with debugging enabled (-ggdb in CFLAGS and splitdebug in FEATURES), see if you can reproduce the crash, and attach the backtrace. Note that abrt sometimes doesn't include the backtrace in its main log file (for example, in the log file you attached, there is no backtrace for the gnome-shell crash). So if that is the case, you need to look for the backtrace file in the appropriate directory under /var/spool/abrt/ or ~/.abrt/spool
i've got only a very small backtrace: #0 0xb6ff12f8 in ?? () from /usr/lib/libmozjs185.so.1.0 Cannot access memory at address 0x7
Created attachment 291007 [details] Backtrace of gnome-shell
Okay, I have added the backtrace which may be of interest to you. I think it is what you are looking for. I have taken your advice and upgraded SINCE creating the backtrace, however the exact same problem with libmozjs.185 persists. Do you require another backtrace, for the newer GDM etc etc?
Updating to gnome-shell-3.2.1-r1 does not fix the problem. The "protection" error in libmozjs185.so persists. I am not a developer (clearly) so I would like to know why I am experiencing this problem with spidermonkey, where other gnome-shell users are not encountering this problem. I have deleted the /tmp folder and all the other stuff in ~/.config dconf gnome etc etc and still no luck.
same for me with gnome-shell-3.2.1-r1. since weeks i have to use kde...
(In reply to comment #7) > I am not a developer (clearly) so I would like to know why I am experiencing > this problem with spidermonkey, where other gnome-shell users are not > encountering this problem. We (the gentoo gnome team) do not know. What is known is the following: 1. At least one other person has reported the same crash (bug #386459), but for him, the gnome-shell-3.2.1 update fixed it. 2. As far as we can tell, line 2838 of jsarray.cpp does not contain any code that could under normal circumstances cause a segfault. So it appears that the crash is being caused by something else. Most probably memory corruption; that hypothesis is indirectly supported by the "previous frame inner to this frame (corrupt stack?)" message in your backtrace. 3. We do not know which package is at fault (is this a problem with spidermonkey? or gjs? or gnome-shell? or something completely different?). Therefore, we cannot tell you to take this bug to upstream developers - we have no idea which upstream is relevant here! 4. Solving this bug would be much simpler if someone on the gnome team could reproduce it - but none of us has ever experienced it. So, what is being done about this bug? When I find spare time, I will try to come up with a sequence of steps that you (as a non-developer) could do to analyze gnome-shell for memory corruption. This might take a while.
I appreciate the feedback Alexandre. Could it be possible that misconfigured USE flags could cause this error? I pulled back to gnome-2.32 and tried to upgrade, and used the keywords etc etc from the gnome overlay. After which the libmozjs.185 error disappeared, BUT the segfaults continued in other apps, such as gnome-settings, glib, libpulse. Is there a reference anywhere which I can turn to, to compare my USE flag set up? (Apologies if this is not the right place to post such questions)
I am seeing the same error after an update to gnome-3.2.1-r1 (from gnome-2.x). Do you have any idea, which USE flag might have changed the behaviour?
Same here. When opengl by nvidia is selected then Segfault with 2 flickers. There are many users that experience this. [ 95.679450] gnome-shell[3049] general protection ip:b6744d23 sp:bf84faa4 error:0 in libmozjs185.so.1.0.0[b6707000+2ee000] [ 96.629390] gnome-shell[3167] general protection ip:b679ad23 sp:bfe51a24 error:0 in libmozjs185.so.1.0.0[b675d000+2ee000] And of course I have tryied most of the mini help by any forums Gentoo, and Archlinux.
Solved! emerge spidermonkey, gjs and gnome-shell command: CFLAGS="-O2 -march=i686" && CXXFLAGS=$CFLAGS emerge -av gnome-shell gjs spidermonkey Please update these packages.
they need the native flags
Found that the problem is only on SpiderMonkey! Only re-emerge spidermonkey and it will be ok!
Created attachment 294339 [details] spidermonkey ebuild with fixed CPU-flag The proposed solution worked for me. Since the problem occured mostely to users with CPU-flag "core2", the attached ebuild replaces only this specific CPU-flag. Please test.
Proposed solution does not work for me. However, you are right with regards to -march=core2 I chose to use distcc on this system, and therefore could not use the "recommended" -march=native CFLAG. This may well be my downfall. Just changing CFLAG to native and a rebuild of spidermonkey gjs gnome-shell does not resolve the problem. Unless I have to rebuild GCC and glibc now as a result of moving away from distcc? (I have removed distcc from the "FEATURES" section of /etc/make.conf Is it possible I now have to rebuild my system as a result of dropping distcc and changing CFLAG back to native?
Created attachment 294511 [details] backtrace of gnome-shell-3.2.1-r1 Same issue here. I tried proposed solution but it doesn't work for me either: [257715.384911] gnome-shell[18780]: segfault at 162 ip b655d24e sp bfccc750 error 4 in libmozjs185.so.1.0.0[b6529000+4a3000] [257715.931072] gnome-shell[18795]: segfault at 162 ip b668624e sp bfce1ba0 error 4 in libmozjs185.so.1.0.0[b6652000+4a3000] different backtrace then before (see attachment).
I have now removed distcc from my system, and rebuilt the system (not world). No change. So now I am rebuilding the world. Not holing my breath. Jirik - I am not a coder, but looking at your recent backtrace, it deffo has something to do with graphics. (Pango, mutter Gdk etc etc)
(In reply to comment #19) > Created attachment 294511 [details] > backtrace of gnome-shell-3.2.1-r1 > > Same issue here. I tried proposed solution but it doesn't work for me either: > > [257715.384911] gnome-shell[18780]: segfault at 162 ip b655d24e sp bfccc750 > error 4 in libmozjs185.so.1.0.0[b6529000+4a3000] > [257715.931072] gnome-shell[18795]: segfault at 162 ip b668624e sp bfce1ba0 > error 4 in libmozjs185.so.1.0.0[b6652000+4a3000] > > different backtrace then before (see attachment). Did you try the ebuild or rather Jimmy Kanes solution (CFLAGS="-O2 -march=i686" && CXXFLAGS=$CFLAGS emerge -av spidermonkey)? Please use this, since the ebuild covers only a small part of Jimmys Solution.
I went through backtrace quickly and look into sources for #0 assertSameCompartment<JSValueArray> (t1=<optimized out>, cx=0xb1ffe0c8) at jscntxtinlines.h:640 636 template <class T1> inline void 637 assertSameCompartment(JSContext *cx, T1 t1) 638 { 639 #ifdef DEBUG 640 START_ASSERT_SAME_COMPARTMENT(); 641 c.check(t1); 642 #endif 643 } so I rebuild spidermonkey without debug flag (and with advised CFLAGS="-O2 -march=i686" && CXXFLAGS=$CFLAGS). Now I successfully got gdm login screen. After login try gnome-settings-daemon crashed: [340489.611468] gnome-settings-[12246]: segfault at b4275d50 ip b4275d50 sp bfe09a6c error 4 in libvorbisfile.so.3.3.4[b4306000+7000] but this looks like another issue.
(In reply to comment #22) > I went through backtrace quickly and look into sources for #0 > assertSameCompartment<JSValueArray> (t1=<optimized out>, cx=0xb1ffe0c8) at > jscntxtinlines.h:640 > > 636 template <class T1> inline void > 637 assertSameCompartment(JSContext *cx, T1 t1) > 638 { > 639 #ifdef DEBUG > 640 START_ASSERT_SAME_COMPARTMENT(); > 641 c.check(t1); > 642 #endif > 643 } > > so I rebuild spidermonkey without debug flag (and with advised CFLAGS="-O2 > -march=i686" && CXXFLAGS=$CFLAGS). Now I successfully got gdm login screen. > After login try gnome-settings-daemon crashed: > > [340489.611468] gnome-settings-[12246]: segfault at b4275d50 ip b4275d50 sp > bfe09a6c error 4 in libvorbisfile.so.3.3.4[b4306000+7000] > > but this looks like another issue. If I understand you right, the previous provided ebuild does not work for you with USE="debug", deactivating debug and setting CFLAGS directly works for you? So could you try to use the ebuild with USE="-debug". Does this provide you with a working spidermonkey?
(In reply to comment #23) > (In reply to comment #22) > > I went through backtrace quickly and look into sources for #0 > > assertSameCompartment<JSValueArray> (t1=<optimized out>, cx=0xb1ffe0c8) at > > jscntxtinlines.h:640 > > > > 636 template <class T1> inline void > > 637 assertSameCompartment(JSContext *cx, T1 t1) > > 638 { > > 639 #ifdef DEBUG > > 640 START_ASSERT_SAME_COMPARTMENT(); > > 641 c.check(t1); > > 642 #endif > > 643 } > > > > so I rebuild spidermonkey without debug flag (and with advised CFLAGS="-O2 > > -march=i686" && CXXFLAGS=$CFLAGS). Now I successfully got gdm login screen. > > After login try gnome-settings-daemon crashed: > > > > [340489.611468] gnome-settings-[12246]: segfault at b4275d50 ip b4275d50 sp > > bfe09a6c error 4 in libvorbisfile.so.3.3.4[b4306000+7000] > > > > but this looks like another issue. > > If I understand you right, the previous provided ebuild does not work for you > with USE="debug", deactivating debug and setting CFLAGS directly works for you? > So could you try to use the ebuild with USE="-debug". Does this provide you > with a working spidermonkey? Yes you understood right. And yes - provided ebuild with USE="-debug" gave me same result as directly set CFLAGS.
The proposed solution did work. I removed the debug flag and recompiled Spidermonkey. I also rebuilt GDM with the gnome-shell USE flag and now I get the nice and shiny OpenGL greeter. I would suggest this is a bug, because my CFLAGS are set to the generic "native" and yet, Spidermonkey still fails. It is only when I install Spidermonkey using said... CFLAGS="-O2 -march=i686" && CXXFLAGS=$CFLAGS emerge -av spidermonkey that I get a working Spidermonkey. Now I can log in to GDM (with OpenGL) and enjoy the standard experience gnome-shell. I suppose the next question is, Why do I have to manually enter i686, and why is emerge not adhering to the "-march-native" CFLAG in my /etc/make.conf ?
So can anyone else confirm that setting the DEBUG USE flag on Spidermonkey, causes it to fail? Should I rename this bug? Open a new one? Or should a developer mark this as "resolved - works for me"? Or do I do that? P.S. gnome-shell is looking / feeling great! Nice work Nirbheek and Alexandre and the rest of the team! You're hard work is extremely appreciated!
Created attachment 295519 [details] spidermonkey-1.8.5 with core2 fix I can confirm, that enabling "debug" leads to a failing spidermonkey. Also in my setup I don't see an effect of setting "-O2" optimizations, the only relevant change is from march=core2 to march=i686. So the attached ebuild works only with USE="-debug" on my core2 system...
You are aware of the fact that a “fix” like filtering flags is never a proper solution, are you? Flags like -march tell the compiler what code to emit. Either the package has a bug, which can only be seen (or is seen earlier) with specific compile flags, because certain optimizations are done. Then the bug in the package has to be found and fixed. Or the compiler itself might be buggy. In this case, the bug in the compiler has to be found and fixed. Working around the problem by not using certain compiler flags asks for the problem to reappear with more recent compiler versions or slight changes to the system which seem not to be related to the bug itself at all.
The official Gentoo (GCC) stance is -march=native, but as I wanted to use distcc this would not be possible. I had to change -march=core2 in order to do that, and that is where spidermonkey is failing. But the problem is still there. In that, I have switched back to -march=native, and rebuilt my entire system, and it still fails. I have to enter the "proposed solution" manually, i.e. -march=i686 and ensure the debug USE flag is not set. Then SpiderMonkey behaves. A GCC-4.5.3-r1 bug perhaps? (but it is marked stable?).
I think it would be worth noting what the failure actually is here. From the backtrace of gnome-shell-3.2.1-r1: #0 assertSameCompartment<JSValueArray> (t1=<optimized out>, cx=0xb1ffe0c8) at jscntxtinlines.h:640 ..this assertion is the one that's failing (and is also the one that is causing the occasional segfault as per bug 386459). The reason for this failure is that there is an attempt at memory access in the script currently being interpreted, that was created or declared or otherwise brought into existence in a different compartment. Proper compartmentalization (especially in a threaded environment) is one of the tricky bits with using spidermonkey-1.8.5, and I expect that this issue stems from a coding or implementation flaw in gnome-shell itself.
Change flag from 'native' ot 'i686' is't resolved my problem: gnome-shell[32746] general protection ip:b67c6da2 sp:bfa3dce4 error:0 in libmozjs185.so.1.0.0[b678c000+2ca000] gnome-shell[453] general protection ip:b690fda2 sp:bfe171b4 error:0 in libmozjs185.so.1.0.0[b68d5000+2ca000]
Created attachment 296035 [details] emerge --info
(In reply to comment #28) > You are aware of the fact that a “fix” like filtering flags is never a proper > solution, are you? > > Flags like -march tell the compiler what code to emit. Either the package has a > bug, which can only be seen (or is seen earlier) with specific compile flags, > because certain optimizations are done. Then the bug in the package has to be > found and fixed. > > Or the compiler itself might be buggy. In this case, the bug in the compiler > has to be found and fixed. > > Working around the problem by not using certain compiler flags asks for the > problem to reappear with more recent compiler versions or slight changes to the > system which seem not to be related to the bug itself at all. Yes, I think we are all aware, that this is not a solution to the problem, its rather a way to find the source. This patch also enables users core2-hardware to use the gnome-shell at all... I wouldnt propose to put this ebuild into the tree although there are several ebuilds, that set special compiler flags... ...and the Makefile of libmozjs185 itself sets several automagical compiler options...
(In reply to comment #33) > ebuilds, that set special compiler flags... > ...and the Makefile of libmozjs185 itself sets several automagical compiler > options... Including -O3 ... Please note that it also causes the same failure on ATOM CPUs with march=native. Reemerging with march=i686 finally is a usable workaround for that machine as well. It's a great relief to have something other then twm as window manager again ....
(In reply to comment #9) > (In reply to comment #7) > > I am not a developer (clearly) so I would like to know why I am experiencing > > this problem with spidermonkey, where other gnome-shell users are not > > encountering this problem. > > We (the gentoo gnome team) do not know. > > What is known is the following: > 1. At least one other person has reported the same crash (bug #386459), but for > him, the gnome-shell-3.2.1 update fixed it. > 2. As far as we can tell, line 2838 of jsarray.cpp does not contain any code > that could under normal circumstances cause a segfault. So it appears that the > crash is being caused by something else. Most probably memory corruption; that > hypothesis is indirectly supported by the "previous frame inner to this frame > (corrupt stack?)" message in your backtrace. > 3. We do not know which package is at fault (is this a problem with > spidermonkey? or gjs? or gnome-shell? or something completely different?). > Therefore, we cannot tell you to take this bug to upstream developers - we have > no idea which upstream is relevant here! > 4. Solving this bug would be much simpler if someone on the gnome team could > reproduce it - but none of us has ever experienced it. > > So, what is being done about this bug? > > When I find spare time, I will try to come up with a sequence of steps that you > (as a non-developer) could do to analyze gnome-shell for memory corruption. > This might take a while. So if a developer was to change their -march=native setting to say core2 or pentium (anything besides the suggested "native") then would they not be able to reproduce this bug? If so, should the status be updated to "confirmed"? It seems to me, if a user changes the default "native" to anything else, then they may encounter the general protection error which some of us are experiencing. But, (hopefully) all users use the "native" CFLAG so this bug will not rear its ugly head. ?? Nonetheless, still a bug?
Having amd64 architecture I am unable to apply "-march=i686", could you please advise? Ebuild trace: checking for gcc... x86_64-pc-linux-gnu-gcc checking whether the C compiler (x86_64-pc-linux-gnu-gcc -march=i686 -mtune=generic -O2 -pipe -Wl,-O1 -Wl,--as-needed) works... no configure: error: installation or configuration problem: C compiler cannot create executables.
I have an "old" Thinkpad X60s with an Intel Core Duo. Actually it is recommended to use -march=prescott, but this led to the same (?) problem as described here, i.e. segmentation faults of gnome-shell in libmozjs185.so (other libraries and programs are also affected, at least here on my installation). After changing to -march=i686 I was able to start gnome-shell at least, but then some other actions led to other segmentation faults in other libraries (gnome-settings-daemon in libgnome...something...). Now I compiled the whole system with the -march=i686 and will try to switch again to gnome-shell and report. For me it seems that either the compiler is the problem or some libraries will cause problems if compiled with optimized march-flags.
(In reply to comment #36) > Having amd64 architecture I am unable to apply "-march=i686", could you please > advise? > > Ebuild trace: > checking for gcc... x86_64-pc-linux-gnu-gcc > checking whether the C compiler (x86_64-pc-linux-gnu-gcc -march=i686 > -mtune=generic -O2 -pipe -Wl,-O1 -Wl,--as-needed) works... no > configure: error: installation or configuration problem: C compiler cannot > create executables. Since "i686" is equivalent to "generic" on i686-architecture you should try "generic" (see http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html), but I have no amd64 architecture here to test. So give it a try?
(In reply to comment #37) > I have an "old" Thinkpad X60s with an Intel Core Duo. Actually it is > recommended to use -march=prescott, but this led to the same (?) problem as > described here, i.e. segmentation faults of gnome-shell in libmozjs185.so > (other libraries and programs are also affected, at least here on my > installation). > > After changing to -march=i686 I was able to start gnome-shell at least, but > then some other actions led to other segmentation faults in other libraries > (gnome-settings-daemon in libgnome...something...). > > Now I compiled the whole system with the -march=i686 and will try to switch > again to gnome-shell and report. > > For me it seems that either the compiler is the problem or some libraries will > cause problems if compiled with optimized march-flags. damn, this also not solved the problem... forget about it...
How can I help to solve the problem? At least for me it seems that a lot of people facing this problem when starting gnome-shell.
(In reply to comment #40) > How can I help to solve the problem? > > At least for me it seems that a lot of people facing this problem when starting > gnome-shell. I am sorry you are still encountering this problem. It seems as if the developers are ignoring posts on this particular bug. I have also asked questions, looking for ideas and confirmation of steps which may reproduce, and it is falling on deaf ears. However, I am fully aware the developers are exceptionally busy (probably with the new Gnome-3.3.3 which is due for release in March.) But a little nod of the head would be nice once in a while. I suppose that is what happens when one encounters an "unconfirmed" bug. The steps I took were as follows: 1. Ensure the "debug" USE flag is not set on spiderminkey. 2. I update my CFLAGS so -march=core2 now reads as -march=native. 3. Rebuilt GCC using the new CFLAGS. 4. Rebuilt entire system (emerge world - and even then, the problem persisted) 5. Used the following command.... CFLAGS="-O2 -march=i686" && CXXFLAGS=$CFLAGS emerge -av spidermonkey Gnome-shell now works - at least that is what fixed it for me. Have you taken the steps as described as above Stefan?
No, cause "native" leads on my system to unbuildable executables. None of my packages is build with debug-use-flag I recompiled the whole system (emerge -e system world) with "i686" which is "generic" for i686-based systems (as mine is: Thinkpad X60s with Intel Core Duo --> actually "prescott" is the correct setting). I am afraid building something with "native" if a single try led to the message above (not exactly same wordin, but...). Should I give it a try anyhow? Which GCC-Version are you using? Mine is 4.5.3. Not to be misunderstood, but I really appreciate the work the people are doing here, but I want to help were I can and if it would only be debugging.
Created attachment 299173 [details] emerge --info from Stefan Struhs
(In reply to comment #43) > Created attachment 299173 [details] > emerge --info from Stefan Struhs Yes try it. The problem is I think, you need to change -march=i686 to "native" and the first thing (most importantly) you should do is rebuild GCC. This might fix the "unbuildable executables" problem. I also have the same version of GCC. Try the above and let me know how you get on.
hello again, so now I compiled the whole system with march=native and then spidermonkey with march=i686. Good news: no segfaults anymore in libmozjs185.so Bad news: segfaults in i915_drv.so and libattr.so.1.10 So, can still not start gnome-shell. Regards, Stefan
(In reply to comment #45) > hello again, > > so now I compiled the whole system with march=native and then spidermonkey with > march=i686. > > Good news: no segfaults anymore in libmozjs185.so > > Bad news: segfaults in i915_drv.so and libattr.so.1.10 > > So, can still not start gnome-shell. > > Regards, > Stefan Hello Stefan, sorry to hear about this. :@( Try running revdep-rebuild to see if it picks this up and fixes it. Also, i915_drv.so could be pertaining to the kernel, so it might also be worth while ensuring you have the latest kernel, or at least, re-compile your existing kernel on your newly built system. Sorry about all of this, and I know it seems endless with all of this compiling, but it is good to go through the process of elimination before posting another bug with regards to these segfaults. Keep us posted, and I will investigate some more later today, to see if I can help you further. Cheers, Thistled.
I've also noticed there is an update to attr, ( [ebuild U ] sys-apps/attr-2.4.46-r1 [2.4.46] ) which may also resolve your problem. So you might want to run an update on your system to see if it resolves this particular problem.
CFLAGS="-O2 -march=native" && CXXFLAGS=$CFLAGS emerge -av gnome-shell gjs spidermonkey with gcc-4.6.2(march=corei7) solved it on my i7 platform
Just to summarize a couple of things in this thread: 1: the 'march' value will only affect the outcome if the various flags GCC is using to compile end up being wrong for your chipset. This can happen, and upgrades to GCC or adjustments to CFLAGS (different 'march' setting or whatnot) will help with this. 2: USE="debug" on dev-lang/spidermonkey should only be used if you are trying to debug something that uses spidermonkey. That flag enables a massive amount of assertion code, which will cause stoppage on things that will not necessarily cause a segfault. It is important to note, though, that having USE="debug" enabled when submitting debug logs helps the developers A LOT in trying to trace back the issue. For general usage, though, definitely do not enable this flag.
(In reply to comment #49) [...] > 2: USE="debug" on dev-lang/spidermonkey should only be used if you are > trying to debug something that uses spidermonkey. That flag enables a > massive amount of assertion code, which will cause stoppage on things that > will not necessarily cause a segfault. It is important to note, though, > that having USE="debug" enabled when submitting debug logs helps the > developers A LOT in trying to trace back the issue. For general usage, > though, definitely do not enable this flag. Would be interesting to note that: http://www.gentoo.org/proj/en/qa/backtraces.xml states it's better to try to get backtrace with debug USE disabled
sys-apps/attr-2.4.46-r1 is installed and the rest of the system is compiled as described before. Unfortunately still unstable gnome3-shell. May gcc-3.6.2 solve the problem? I still use gcc-3.5.3-r2. Or is it better to stop trying to get gnome3-shell working. Maybe switching to kde or a more light-weight desktop would be better? The other successor of gnome2... forgot the name.
(In reply to comment #50) > (In reply to comment #49) > [...] > > 2: USE="debug" on dev-lang/spidermonkey should only be used if you are > > trying to debug something that uses spidermonkey. That flag enables a > > massive amount of assertion code, which will cause stoppage on things that > > will not necessarily cause a segfault. It is important to note, though, > > that having USE="debug" enabled when submitting debug logs helps the > > developers A LOT in trying to trace back the issue. For general usage, > > though, definitely do not enable this flag. > > Would be interesting to note that: > http://www.gentoo.org/proj/en/qa/backtraces.xml > > states it's better to try to get backtrace with debug USE disabled That's what I thought.
Is this still valid with 3.4.2?
(In reply to comment #53) > Is this still valid with 3.4.2? I don't think so Pacho. I can log in without a problem. I seem to be experiencing random system freezes, but that is entirely unrelated to the spidermonkey error I was experiencing. Thanks.
Thanks for feedback :)
