It's barely usable as it crashes randomly... Reproducible: Always Portage 2.2.20.1 (python 2.7.10-final-0, default/linux/amd64/13.0/desktop, gcc-4.9.3, glibc-2.20-r2, 3.18.12-gentoo x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.18.12-gentoo-x86_64-AMD_Turion-tm-_64_X2-with-gentoo-2.2 KiB Mem: 3920908 total, 1803596 free KiB Swap: 3148736 total, 3148736 free Timestamp of repository gentoo: Sun, 11 Oct 2015 17:00:01 +0000 sh bash 4.3_p39 ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1 app-shells/bash: 4.3_p39::gentoo dev-java/java-config: 2.2.0::gentoo dev-lang/perl: 5.20.2::gentoo dev-lang/python: 2.7.10::gentoo, 3.3.5-r1::gentoo, 3.4.3::gentoo dev-util/cmake: 3.2.2::gentoo dev-util/pkgconfig: 0.28-r2::gentoo sys-apps/baselayout: 2.2::gentoo sys-apps/openrc: 0.17::gentoo sys-apps/sandbox: 2.6-r1::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69::gentoo sys-devel/automake: 1.11.6-r1::gentoo, 1.12.6::gentoo, 1.13.4::gentoo, 1.14.1::gentoo, 1.15::gentoo sys-devel/binutils: 2.25.1-r1::gentoo sys-devel/gcc: 4.7.3-r1::gentoo, 4.8.5::gentoo, 4.9.3::gentoo sys-devel/gcc-config: 1.7.3::gentoo sys-devel/libtool: 2.4.6::gentoo sys-devel/make: 4.1-r1::gentoo sys-kernel/linux-headers: 3.18::gentoo (virtual/os-headers) sys-libs/glibc: 2.20-r2::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 unsupported location: /var/portage/overlay/unsupported masters: gentoo priority: 0 sunrise location: /var/lib/layman/sunrise masters: gentoo priority: 1 Installed sets: @audio, @dev, @emacs, @emul, @fonts, @gkrellm, @graphix, @net, @office, @utilz, @video, @xfce ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib64/fax /usr/share/gnupg/qualified.txt /var/spool/fax/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.5/ext-active/ /etc/php/cgi-php5.5/ext-active/ /etc/php/cli-php5.5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch parallel-install preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://mirror.switch.ch/ftp/mirror/gentoo/ ftp://mirror.switch.ch/mirror/gentoo/" INSTALL_MASK="/usr/lib/systemd/" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" USE="3dnow 3dnowext X a52 aac acpi alsa amd64 amr apng bash-completion berkdb bittorrent bluetooth branding bzip2 cairo calendar caps cdda cddb cdparanoia cdr cleartype cli consolekit corefonts cracklib crypt cups curl cvs cxx dbus djvu dts dvd dvdr ebook emacs embedded emboss enchant encode exif fam fbcon ffmpeg firefox flac fortran gdbm gif git glamor gnutls gpm h323 http hunspell iconv icu id3tag jabber jack jp2k jpeg jpeg2k kontact kpathsea ladspa lame laptop latex lcms ldap libnotify libsamplerate lxde mad matroska mmx mmxext mng modules mp3 mp4 mpeg mplayer multilib musepack musicbrainz mysql ncurses nls nptl ntfs ntfsprogs ofx ogg opengl openmp openvg opus pam pango pcre pdf pgo png policykit ppds quicktime readline real rtmp samba sdl seamonkey seccomp session spell sql sqlite sse sse2 ssh ssl startup-notification svg system-cairo system-icu system-jpeg system-libvpx system-sqlite taglib tcpd threads thunar tiff tordns truetype udev udisks unicode upower usb v4l v4l2 video vlc vorbis wavpack wifixvfb wxwidgets x264 xcb xetex xml xv xvid zlib" ABI_X86="64" ALSA_CARDS="hda-intel usb-audio" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="3dnow 3dnowext mmx mmxext sse sse2 sse3" DRACUT_MODULES="crypt lvm" 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 ublox ubx" GRUB_PLATFORMS="pc" INPUT_DEVICES="keyboard mouse synaptics evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4" RUBY_TARGETS="ruby20 ruby21" SANE_BACKENDS="epson2 epkowa" USERLAND="GNU" VIDEO_CARDS="nvidia modesetting vesa" 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: CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON ================================================================= Package Settings ================================================================= www-client/seamonkey-2.38::gentoo was built with the following: USE="crypt dbus gmp-autoupdate gstreamer ipc jemalloc3 jit startup-notification system-cairo system-icu system-jpeg system-libvpx system-sqlite -chatzilla -custom-cflags -custom-optimization -debug -gstreamer-0 -minimal -pulseaudio -roaming (-selinux) -test -wifi" ABI_X86="64" LINGUAS="-be -ca -cs -de -en_GB -es_AR -es_ES -fi -fr -gl -hu -it -ja -lt -nb_NO -nl -pl -pt_PT -ru -sk -sv_SE -tr -uk -zh_CN -zh_TW" CFLAGS="-march=native -pipe -mno-avx" CXXFLAGS="-march=native -pipe -mno-avx"
Ditto with seeing multiple random segmentation faults within both recent Mozilla firefox and seamonkey for the past week or so. Try recompiling both www-client/seamonkey, dev-db/sqlite and sys-libs/glibc with USE="debug" ie: # USE="debug" emerge -q www-client/seamonkey dev-db/sqlite sys-libs/glibc Or add the file names to your /etc/portage/package.use file. Execute seamonkey (or firefox) using command line, and within another shell enter the gdb command incanatation given by seamonkey/firefox stdout logging. (ie. gdb seamonkey 16842) Type "bt" or backtrace and past the beginning of the stack output. The bug will like be within the top line, naming a file. (In my case, the file belongs to glibc, as to why I also gave you another package to compile with the debug flags. Also, add FEATURES="splitdebug" so that symbols are saved for these packages rebuilt. If you're good at using Gentoo, you likely also know you can temporarily enable this feature via the command line variable as I've advised above. For example: # FEATURES="splitdebug" USE="debug" emerge -q www-client/seamonkey dev-db/sqlite sys-libs/glibc On my system, I have splitdebug as default for all packages.
1) I updated glibc to the latest available version. 2) Migrated from the old profile to a fresh profile. Moved my $HOME/.mozilla folder to $HOME/.mozilla-20151017 3) Created the $HOME/.mozilla/seamonkey/$PROFILE and copied over: $HOME/.mozilla/seamonkey/profiles.ini $HOME/.mozilla/seamonkey/$PROFILE.default/key3.db $HOME/.mozilla/seamonkey/wbds0kju.default/logins.json $HOME/.mozilla/seamonkey/$POFILE.default/signons.sqlite 4) Copied over all archived bookmarks folder: $HOME/.mozilla/seamonkey/wbds0kju.default/bookmarkbackups 5) Imported the old bookmarks using Bookmarks > Manage Bookmarks > Restore > Choose file option. I'm back up and running the browser and haven't seen a crash yet. Using the USE=debug option with Firefox/Seamonkey doesn't seem to be very productive here. The debug option seems to significantly slow any loading pages from the Internet to a significant stall. At this point, it could be the glibc bug or related to the glibc bug, or bugged upgrade from seamonkey-2.35 to seamonkey-2.38. Something surely wasn't not correct, and tracing was extremely difficult with Mozilla's debug language.
This bug will teach those in Wiki page management and remind a few others concerning browser stability, that it's a good thing when users save and publish each WIKI change! If they don't publish each change as soon as possible, they then risk loosing lots of data by waiting to push all changes within one change when using their browser! The longer the wait, the more inevitable a crash will occur.
I'm finally getting some useful debug data to stdout using the following: # cat /etc/portage/env/debug.conf # Debug Options CFLAGS="-Og -Wall -g -ggdb" CXXFLAGS="${CFLAGS}" FEATURES="splitdebug installsources" Disregard using USE="debug" for seamonkey and firefox, from my previous comments. (This USE option pretty much seems to make the applications unusable, and maybe more useful for other types of bugs.) Add the following packages to /etc/portage/package.env www-client/seamonkey dev-db/sqlite sys-libs/glibc (optional) www-client/firefox (optional) You're adding packages here in event the bug is traced outside of seamonkey's package. So far, the above is pretty much what I have, but might not be needed. Now when seamonkey segfaults, a core file is generated within the folder seamonkey is run from. So within a shell within your $HOME, execute seamonkey. Upon segfault, use "gdb --core=core /usr/bin/seamonkey" Type "bt" to see more of the backtrace. I can further see the source code within the backtrace without problem, and can further see some GCC related code executed just prior to my segfault signal being raised.
@Roger, thanks for tips. Unfortunately, I have no time for debugging this -- this is also my only Gentoo installation and must stay as stable as possible. However, I downgraded SM to v2.35 which is running fine -- no crash in several days so far. There's a crash report upstream, possibly related to the Flash Plugin (though on WOW64): <https://bugzilla.mozilla.org/show_bug.cgi?id=1211359>... Meanwhile I upgraded Flash in my box to 'www-plugins/adobe-flash-11.2.202.535', maybe that's a path to investigate.
I do not think I had Adobe Flash enabled within my previous Mozilla profiles, but I may have missed the fact the flash plugin could have been active all along. (Always missing something while debugging!) Yes, even on my clean install, I just found Adobe Flash plugin set to Always Activate. Proprietary binary stuff is so difficult to trace, and this may have been why here. Only time now will show if my bug was related, as the plugin is now (as the flash plugin usually is) deactivated. Just unknowingly updated the Adobe Flash plugin today, www-plugins/adobe-flash-11.2.202.535 updated to 11.2.202.521 version.
One thing that I find odd concerning my segfault and the Adobe Flash plugin segfault, the reporter was able to get a $HOME/.mozilla-20151016/seamonkey/$PROFILE.default/Crash\ Report folder containing crash reports. Looking at my configuration settings (about:config) with crash/breakpad settings, BreakPad is activated here. And yet I see no Crash\ Report folder. I'll just relax for now, and wait and see how stability progresses.
$ locate "Crash Reports" I haven't seen any crash reports since November 2012 here.
(In reply to Roger from comment #8) > $ locate "Crash Reports" > > I haven't seen any crash reports since November 2012 here. Possibly that's because, IIRC, gentoo builds don't have the "about:crashes" handler compiled in, as the debugging strategy is different. If you manage to get core dumps, the shell function `gdb_get_backtrace()` should be better way to extract a useful BT, as explained here: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces#Core_dumps HTH!
FYI: "Also, crash reporter does not work for applications built for and run in 64 bit mode." (http://kb.mozillazine.org/Breakpad) I wasn't aware of this. The 2012 configuration file, now that I recall, was likely from one of my 32bit boxes. My $HOME/.gdbinit configuration file already implements the gdb_get_backtrace() bashrc function listed on Gentoo's core dump debugging page. Albeit, the gdb_get_backtrace() is a sweet little function.
Seamonkey-2.38 is based on firefox-40 or firefox-41, and so it's likely that the random crashing issues are related to (A) system-cairo, (B) the 'layers.offmainthreadcomposition.enabled' pref in about:config set to true, (C) flash plugin and freshplayerplugin being installed at the same time, or any combination. See bug 558150 for related comments. seamonkey-2.35 is based on firefox-38.x, which doesn't have the same crashiness.
For me, negative concerning another of the fore-mentioned within Ian's comments. I've filed my random segmentation fault bug upstream to Mozilla, along with a backtrace with Seamonkey compiled using debug CFLAGS without the USE="debug" flag set. (ie. gdb --core=./core seamonkey and entered "bt") (I thought Seamonkey and Firefox were based-off over Mozilla core code, Seamonkey being the more ancient branch, with Firefox being a later trimmed down version of the browser with the EMail client spun into Thunderbird.)
(In reply to Roger from comment #12) > (I thought Seamonkey and Firefox were based-off over Mozilla core code, > Seamonkey being the more ancient branch, with Firefox being a later trimmed > down version of the browser with the EMail client spun into Thunderbird.) The mozilla core codebase and the firefox codebase are essentially the same thing. Seamonkey itself is actually the "comm" codebase, which wraps around the "mozilla" codebase -- thunderbird ("mail" project) and seamonkey ("suite" project) are both part of comm. Seamonkey uses the same release branch that firefox does for the main core browser functionality, although of course it uses its own completely different front-end. So a lot of the bugs (including security bugs) are going to affect both projects. I'm not particularily involved in seamonkey so the specific details of what's the same and what's different would be better answered by others, but this is the general gist of how the mozilla-based packages are structured. Regarding the crashreporter note you mentioned in an earlier comment, so far as I am aware it works just fine for 64bit and 32bit alike now (assuming seamonkey generates them at all--i don't know the status of that), but if you are building seamonkey from source the crashreporter is (or should be) expressly disabled -- the mozilla product teams only want generated crash reports when the builds are done on mozilla infra, otherwise they can get too many issues reported that are due to build or configuration issues. The crashreporter submissions feed profiling/data-mining activities and those won't work well when the binaries used don't match across all systems.
Thanks Ian. I think you're pretty much correct with everything you stated within your last post. I tend to agree, even with the Mozilla crash reporter likely not being compiled in due to unique build environments. (On the flip if I were a Mozilla developer, I'd want those crash reports from unique build environment in order to stabilize the project further. So shrugs. Depends on who's running the show.)
Still getting random segfaults using seamonkey-2.39! See my upstream bug report, Mozilla Bug 1216765 https://bugzilla.mozilla.org/show_bug.cgi?id=1216765
FYI: If you don't know already, try using www-client/seamonkey-bin instead. (I could have sworn Gentoo's Portage package folder tree was missing seamonkey-bin recently, else I was just searching installed packages instead of all packages.)
I have the same problem and in my case (2.38) it seems to be connected to use flag system-cairo as Ian pointed out. Same for 32 and 64 bit machines. Without system-cairo the crashes seem to be gone, there are still some crashes now and then but they may be flash related. I haven't tried 2.39 yet but if it is confirmed to be due to cairo, I'll suggest to mask the system-cairo use flag until the problem is fixed or to add a dependency to a working cairo version.
I would strongly suggest verifying Adobe Flash is causing your remaining segfaults before suggesting masking system-cairo. In the meantime, I think I can more easily verify by simply rebuilding seamonkey-2.38/2.39 without using system-cairo. Also, I can utilize my debug.conf for building cairo against. (ie. package.env) If the segfaults are happening here, the backtrace should surely show. However if you notice, most all backtraces I've loaded upstream do not show any apparent untraceable code. (It is also noted cairo CFLAGS causes problems with Adobe Reader within my package.env, but due to likely unmaintained Adobe Reader proprietary binary-only out-dated code! Hence, likely off-topic but somewhat note worthy.)
Please also test seamonkey[system-cairo] with x11-libs/cairo being compiled with "xlib-xcb" USE flag being enabled and report your results here.
(In reply to Lars Wendler (Polynomial-C) from comment #19) > Please also test seamonkey[system-cairo] with x11-libs/cairo being compiled > with "xlib-xcb" USE flag being enabled and report your results here. negative do not enable xlib-xcb, refer to force enabling hardware acceleration, you can find an example via the pref in mozilla overlay for firefox. pref("layers.acceleration.force-enabled", true); pref("webgl.force-enabled", true); Please ensure you also have layers.offmainthreadcomposition.enabled set to default which should be true. Do not enable xlib-xcb useflag this will for sure cause a crash, also if your using firefox with egl useflag disable it it is known to cause major slow downs when using hardware acceleration.
OK, my cairo does not use xlib-xcb. As said, seamonkey without system-cairo works quite stable. The crashes have nothing to do with Flash as there were no flash containing web pages open at the time of the crash(es). It crashed even while typing e-mail. So as it seems to me it is due to system cairo version and masking the use flag (or depend of the right cairo version) until the issue is resolved seems as an acceptable solution to me.
(In reply to Konstantin Münning from comment #21) > OK, my cairo does not use xlib-xcb. As said, seamonkey without system-cairo > works quite stable. The crashes have nothing to do with Flash as there were > no flash containing web pages open at the time of the crash(es). It crashed > even while typing e-mail. So as it seems to me it is due to system cairo > version and masking the use flag (or depend of the right cairo version) > until the issue is resolved seems as an acceptable solution to me. For one system-cairo is not even supported upstream, they use a hacked up old version. We will not mask the useflag there is no point, I am still waiting for the results of testing with hardware acceleration enabled. Once you can provide that we can do a revision bump with the fix so all user will benefit.
I haven't examined every detail of the previous messages, but so far compiling x11-libs/cairo using CFLAGS="-Og -Wall -g -ggdb" >=seamonkey-2.38 seems quite stable so far. I'll know for sure with another days use of seamonkey to know for sure, but so far I've performed quite a bit of a researching upon many domains and have yet to see a segfault. (Still too soon though to conclude. Tomorrow or the next day I'll likely have a better clue!)
Nope. Just received another segfault using seamonkey-2.39 with cairo compiled with debug flags. Nothing really found within the backtrace either still. Next, compile out (-system-cairo) and use static seamonkey cairo.
(In reply to Jory A. Pratt from comment #22) > For one system-cairo is not even supported upstream, they use a hacked up > old version. We will not mask the useflag there is no point, I am still > waiting for the results of testing with hardware acceleration enabled. Once > you can provide that we can do a revision bump with the fix so all user will > benefit. As for the preferences, I had it always running with the default settings of layers.acceleration.force-enabled, layers.offmainthreadcomposition.enabled and webgl.force-enabled. The egl use flag was enabled all the time. So in my case the only difference was the system-cairo flag. Is this the testing with hardware acceleration enabled you are waiting for or what other constellation do you need? For my understanding, why there is no point in masking this use flag for seamonkey when it is not supported upstream and there is evidence of crashes caused by that? If it is needed for trying new things, then at least a warning should be printed to inform that if seamonkey starts crashing it should be tried without system-cairo.
But you have to realize, if one simply masks packages at will and every whim, where are you going to get the backtraces to find and resolve the bug? Not getting any testing or backtraces and the bugs pile-up, rendering packages or features unmaintained, and unfixable after longer time spans. Anyways, I'm testing with static cairo now,and will report if I get segfaults, or within two days to report any possible success.
(In reply to Jory A. Pratt from comment #20) > pref("layers.acceleration.force-enabled", true); > pref("webgl.force-enabled", true); > pref("layers.offmainthreadcomposition.enabled", true); The above prefs flags are what have been pushed to the tree for Firefox-42, which shares the same core codebase as seamonkey-2.39. With this configuration set and I believe also some patches that Jory has added, firefox-42 with USE="system-cairo" has finally become stable again. Seamonkey-2.39 at this time does not have these prefs set by default in the ebuild but they should help to stabilize it when USE="system-cairo" is set as well.
Thanks Ian for your more sound explanation here. This would explain a lot. I'll continue my testing to verify.
Using static cairo seems to have made seamonkey-2.38/2.39 stable here, as I haven't seen any segfaults yet. Any word from anybody else using the above prefs? Is somebody in the process of porting the firefox prefs to seamonkey? And has anybody else tested the prefs and find their seamonkey stable? I'll be happy to port the patch over once I can hear others verify they're now stable. I haven't tested the prefs yet, and will be testing shortly.
FYI: I'm not seeing any patches for current stable firefox-38.4.0 (and likely firefox-42 & firefox-43) relevant for patching it's sources concerning the prefs previously mentioned. (ie. See Comment #20; pref("layers.acceleration.force-enabled", pref("webgl.force-enabled", "layers.offmainthreadcomposition.enabled", ...) I'd like to apply the patches manually, versus mucking around with my personal Mozilla preferences file and later forgetting those changes.
(In reply to Roger from comment #30) > FYI: I'm not seeing any patches for current stable firefox-38.4.0 (and > likely firefox-42 & firefox-43) relevant for patching it's sources > concerning the prefs previously mentioned. (ie. See Comment #20; > pref("layers.acceleration.force-enabled", pref("webgl.force-enabled", > "layers.offmainthreadcomposition.enabled", ...) > > I'd like to apply the patches manually, versus mucking around with my > personal Mozilla preferences file and later forgetting those changes. we do not patch anything we provide a gentoo pref to the install and add it via the omni.jar file that is created during make install.
(In reply to Roger from comment #30) > FYI: I'm not seeing any patches for current stable firefox-38.4.0 (and > likely firefox-42 & firefox-43) relevant for patching it's sources > concerning the prefs previously mentioned. (ie. See Comment #20; > pref("layers.acceleration.force-enabled", pref("webgl.force-enabled", > "layers.offmainthreadcomposition.enabled", ...) Also, seamonkey-2.35 and firefox-38.x don't need these settings. It's everything (so far at least) past firefox-39 and seamonkey-2.38 that need them.
OK. Just rebuilt seamonkey-2.39 with USE="system-cairo system-icu system-jpeg system-sqlite" and set the about:config prefs as stated within Comment #20: pref("layers.acceleration.force-enabled", true); pref("webgl.force-enabled", true); NOTE: The reason why many others are likely not experiencing this wonderful bug, "system-cairo system-icu system-jpeg system-sqlite" are likely disabled by default. Will report back with my experience. If you don't hear from me within one to two days, likely means I have not experienced a segfault yet.
Boy that didn't take much time for another segfault with the about about:config settings and system-cairo! As I speculated earlier, maybe the segfault is occurring within nvidia-drivers or code using nvidia-drivers functions! (ie. Nothing really indicating the source of the break within gdb backtraces, and is a common clue the break is occurring within binary/proprietary code.) Anyways, I do not know why I've been using system-cairo (as well as other system-*) USE flags for seamonkey, but I'll revert to default USE flags until I remember why. All default USE flags except using gstreamer USE flag, as gstreamer is required for the new YouTube/Google videos protocol not requiring Adobe Flag. At least we know the cause is within system-cairo. I'm guessing somebody now needs to load an Xorg session only using the open source nouveau to rule-out nvidia-drivers.
My backtraces (including the recent backtrace) are all uploaded to upstream Mozilla Bugzilla Bug 1216765 - Random Segmentation Fault with Seamonkey http://bugzilla.mozilla.org/show_bug.cgi?id=1216765
(In reply to Roger from comment #35) > My backtraces (including the recent backtrace) are all uploaded to upstream > Mozilla Bugzilla > > Bug 1216765 - Random Segmentation Fault with Seamonkey > http://bugzilla.mozilla.org/show_bug.cgi?id=1216765 Please do not open an upstream bug unless requested by a member of the mozilla gentoo team. These are not issues that upstream is concerned with, if they can not duplicate the issue with the -bin package they provide they will close it invalid for unsupported config.
I just found a note concerning this cairo related crash here: http://www.linuxfromscratch.org/blfs/view/svn/xsoft/firefox.html # From firefox-40, using system cairo causes firefox to crash # frequently when it is doing background rendering in a tab. Searching the Internet again doesn't really reveal an open bug concerning the fore mentioned.
As far as upstream bugs concerning unsupported mozconfig configurations, I would heavily post within multiple places that unsupoorted mozconfig configurations are not supported upstream by Mozilla. If something breaks, first check the binary build and also use default mozconfig configurations. I would also further elaborate on the supported and unsupported configurations. It is probably also best to place this documentation at the top of a debugging page or other page dealing with bugs within Mozilla products. Assuming people are going to know this probably isn't a good idea, nor will people adhere to the policy 100%. (However, I think Mozilla over-looks this practice as they want to at least hear about the bug, and do not want to deter bugs being found.) The following most popular Gentoo sources do not iterate the unsupported mozconfig configurations: https://wiki.gentoo.org/wiki/Project:Mozilla https://wiki.gentoo.org/wiki/Project:Mozilla www-client/firefox ebuilds www-client/seamonkey ebuilds However searching the Internet for Mozilla material mentions "selected non-default configuration options are unsupported or not recommended, and may result in your build not building correctly or executing correctly." https://developer.mozilla.org/en-US/docs/Configuring_Build_Options Nowhere within the above documentation do they (Mozilla) out-law filing a bug against such configurations. If I were on the project, I'd want to hear about any bugs, and might briefly advise unsupported mozconfig configurations are not supported.
I forgot to mention "https://wiki.gentoo.org/wiki/Firefox", and incorrectly doubled a copy/paste within the above post. I should mention the Firefox wiki does have a good start for at least mentioning recommended mozconfig configurations, but nothing more.
Just guessing, maybe you are hitting this bug? https://bugzilla.mozilla.org/show_bug.cgi?id=1230746 Start seamoneky from xterm and let it opened via: $ seamonkey & You will get debug messages in the window. The FEATURES=splitdebug and USE=debug is mostly enough for me although I use CFLAGS="-ggdb". However, some of the subdirectories in seamonkey sources override my CFLAGS so some parts of the stacktrace cannot be resolved.
The previously mentioned "cairo-scaled-font.c:459: _cairo_scaled_glyph_page_destroy: Assertion `!scaled_font->cache_frozen' failed." bug looks related to this one. I too use splitdebug with great success I might add, but never really had any better backtraces. Using the seamonkey USE debug flag caused significant overhead, and then trying to reproduce was just too much for my 4 core plus 4 threaded i7-3770K CPU. It took me awhile to realize why seamonkey was not doing anything, I had to sit all day waiting for one page to load. This bug would only present itself after some time loading multiple pages at random. You are probably correct, Seamonkey seems to be having significant problems just loading in it's own backtrace! (ie. Even with "debug" disabled, the backtrace should have loaded as we were using external cairo system libs.) Sounds like semantics.
Testing (~)2.40_pre4. <sarcasm> Just slightly better than 2.3[8,9]: it now gives you enough time to make you swear like hell as your 500-word important e-mail goes to the segfault drain. </sarcasm> Seriously, any improvement on this? Why still unconfirmed? v2.35 was *rock* solid...
Seems to be another separate segfault occurring recently. Just haven't had much interest here documenting this very recent second segfault here. I would suggest just using seamonkey-bin.
Testing v2.40: no progress wrt v2.40_pre4, still crashing :-( Though, much better than v2.38: this is usable -- needs just a bit more vigilance on relevant tasks with CTRL+S.
Created attachment 430412 [details] Crash backtrace Only SM was compiled with '-ggdb' thus not all symbols are resolved...
Update with more debug info. Please note that only SM was compiled with '-ggdb' thus not all symbols are resolved: if that's not enough, let me know what other dependencies should be recompiled.
Created attachment 430414 [details] emerge --info for SM-2.40
Created attachment 430416 [details] emerge --info for SM-2.40
Comment on attachment 430414 [details] emerge --info for SM-2.40 Fu**ing hell, crashed again while submitting and ended up with a double entry...
If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system. Thank You for your support and understanding The Mozilla Team
Nope. Been using seamonkey-bin instead.
