805 bytes, patch
Robert Relyea: superreview+
Benjamin Smedberg: approval1.9.2+
|Details | Diff | Splinter Review|
413 bytes, patch
|Details | Diff | Splinter Review|
4.88 KB, text/plain
Gecko can work around bug 497251 by building NSS with FREEBL_NO_DEPEND on Linux until Fedora and NSS decide on an ABI for libfreebl3.so. Building with FREEBL_NO_DEPEND means that libfreebl3.so will have the ABI that libcrypt.so.1 expects on Fedora 11. This also includes the ABI provided when NSS is built in the default configuration. Another difference with FREEBL_NO_DEPEND is that libnspr4.so and libnssutil3.so are loaded through dlopen instead of the runtime linker. This functionality is not needed but talos didn't detect any perf issues. Using FREEBL_NO_DEPEND increases the size of libfreebl3.so from 317036 to 321140 bytes.
Created attachment 397045 [details] [diff] [review] patch As suggested by wtc in bug 497251 comment 59. Try server builds currently here: https://email@example.com/
Created attachment 397057 [details] [diff] [review] patch v1.1 Let's do it. (I added a comment to your patch.)
Comment on attachment 397057 [details] [diff] [review] patch v1.1 Thanks.
Comment on attachment 397057 [details] [diff] [review] patch v1.1 I pushed this patch to mozilla-central in changeset 1aafaa610c9f: http://hg.mozilla.org/mozilla-central/rev/1aafaa610c9f
Created attachment 397158 [details] [diff] [review] Companion patch (dummy change to security/coreconf/coreconf.dep) We also need to touch security/coreconf/coreconf.dep so that the files in security/nss/lib/freebl will be recompiled with the new FREEBL_NO_DEPEND=1 setting, otherwise we will get a linker error (unresolved symbols). Any change to security/coreconf/coreconf.dep is fine. We usually just delete or add a blank line at the end of the file. This change must accompany the real patch (attachment 397057 [review]) when it is pushed to mozilla-1.9.2 or mozilla-1.9.1.
Comment on attachment 397158 [details] [diff] [review] Companion patch (dummy change to security/coreconf/coreconf.dep) I forgot to mention that I already pushed the companion patch to mozilla-central in changeset d58fbf114c7a: http://hg.mozilla.org/mozilla-central/rev/d58fbf114c7a
Comment on attachment 397057 [details] [diff] [review] patch v1.1 r+ let's go ahead and try this.
> I'd appreciate it if someone experiencing this crash (with Fedora 11) could > test the build linked there, please. Note that the build is based on trunk, > so I suggest either back up your profile or "mkdir ~/tmp/new-profile" and > run with "-profile ~/tmp/new-profile -no-remote". I have attempted to use the firefox provided at your link: https://firstname.lastname@example.org/try-1ba192569f3b-linux.tar.bz2 using the command that you specified: $ ./firefox -profile ~/tmp/new-profile -no-remote This results in the following errors: firefox/firefox-bin: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory firefox/run-mozilla.sh: line 143: firefox/firefox-bin: Success This is on (a recently installed) 64-bit Fedora 11. $ uname -ioprv 22.214.171.124-217.2.16.fc11.x86_64 #1 SMP Mon Aug 24 17:17:40 EDT 2009 x86_64 x86_64 GNU/Linux $ sha1sum ./firefox ./firefox-bin 9a773299773700205d420333e3b367ca98a76b0e ./firefox 4fe280a4580249cb21a6ce703f21229e98d79f07 ./firefox-bin
Thanks. (In reply to comment #8) > firefox/firefox-bin: /lib/ld-linux.so.2: bad ELF interpreter: No such file or > directory That looks like /lib/ld-linux.so.2 is missing, and that is usually necessary for running 32-bit executables. There is a 64-bit executable in the nightly trunk builds, which now have this change: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
(In reply to comment #9) > > There is a 64-bit executable in the nightly trunk builds, which now have this > change: > > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ Thank you. I downloaded the x86_64 .tar.gz. Unfortunately, firefox is still crashing. Note that the newly-built version has (for my setup) the same trait as the released version, namely, some flash content will play without problems, and other content will cause firefox to halt with on an illegal instruction almost immediately (before playing any flash video). Here are the details of the steps I took: 1. Downloaded http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-3.7a1pre.en-US.linux-x86_64.tar.bz2 $ sha1sum firefox-3.7a1pre.en-US.linux-x86_64.tar.bz2 13cb17bef5881031902bd2cfa5e8b29754e3fd51 firefox-3.7a1pre.en-US.linux-x86_64.tar.bz2 2. Extracted contents to a new directory. 3. Copied the 64-bit flash plugin/library 'libflashplayer.so' to the 'firefox/plugins' sub-directory: - http://labs.adobe.com/downloads/flashplayer10.html provides http://download.macromedia.com/pub/labs/flashplayer10/libflashplayer-10.0.32.18.linux-x86_64.so.tar.gz $ sha1sum firefox/plugins/libflashplayer.so 8ec78fc69293eccc6aad3cb6272ba6356a522fe0 firefox/plugins/libflashplayer.so $ ls firefox/plugins/ libflashplayer.so* libnullplugin.so* $ sha1sum firefox/libfreebl3.chk firefox/libfreebl3.so 7eaee510e548a4c2fa2a25ca50bfb121e666aad1 firefox/libfreebl3.chk 39826ad90c6a96344fd6f895f968abcd84fc0dc6 firefox/libfreebl3.so 4. Started 'firefox' with no location/URL specified and selected the location 'about:plugins' to confirm that only the above two plugins were known/loaded. From the 'about:plugins' screen: File: libnullplugin.so Version: 126.96.36.199 File: libflashplayer.so Version: Shockwave Flash 10.0 r32 5. Attempted to play the following content http://www.youtube.com/watch?v=32wIKaLkvc4&NR=1 $ ./firefox -profile ~/tmp/new-profile -no-remote http://youtube.com/watch?v=32wIKaLkvc4&NR=1 Content plays without error, both sound and video. 6. Attempted to play the following content http://www.youtube.com/falltvpreview: $ ./firefox -profile ~/tmp/new-profile -no-remote http://youtube.com/falltvpreview nsGREResProperties charsetalias.properties (firefox-bin:4826): Gdk-WARNING **: XID collision, trouble ahead + Done ./firefox -profile ~/tmp/new-profile -no-remote http://youtube.com/watch?v=32wIKaLkvc4 Illegal instruction $ echo $? 132 For what it is worth, the above behavior is mirrored by the web browsers 'seamonkey', 'galeon', and 'epiphany', that is, all four web browsers successfully play the content at the first URL above and all four halt with the 'Illegal instruction' error on the content at the second URL. (On another computer, Fedora 10 plays the content at both URLs without error in all four web browsers.) $ rpm -q seamonkey galeon epiphany nss-softokn-freebl seamonkey-1.1.17-1.fc11.x86_64 galeon-2.0.7-13.fc11.x86_64 epiphany-2.26.3-3.fc11.x86_64 nss-softokn-freebl-188.8.131.52.3-2.11.4.fc11.x86_64
Created attachment 397418 [details] Assertion failures listed while running firefox-3.5.2-2.fc11.x86_64 under gdb Here is some additional information about the firefox crash while attempting to open/play the content at the URL 'http://www.youtube.com/falltvpreview'. Instead of the custom 'Minefield' version, I had to use the current Fedora 11 firefox version to use the debug information files that Fedora provides.
idirectscm: The issues that you are seeing seem different from bug 497251. In bug 497251, Mozilla's builds crash with SIGSEGV but Fedora's builds do not have that crash. The issue that you are reporting is a crash with SIGILL that happens event with Fedora's builds. If you can get a stack trace of a crash, then it may be worth filing another bug.
As expected, we haven't had any of these crash reports on trunk for some time.
(In reply to comment #12) > idirectscm: The issues that you are seeing seem different from bug 497251. > In bug 497251, Mozilla's builds crash with SIGSEGV but Fedora's builds do not > have that crash. The issue that you are reporting is a crash with SIGILL that > happens event with Fedora's builds. If you can get a stack trace of a crash, > then it may be worth filing another bug. OK. Thanks. 1. You are correct that I am seeing a SIGILL (Illegal Instruction) error. I have generated a (large, multi-threaded) stack trace for this and will file it with Fedora's Bugzilla, either with an existing defect report or a new one. 2. It appears that someone else had reported a a SIGSEGV on Fedora 11. Please see https://bugzilla.redhat.com/show_bug.cgi?id=505365#c70 if you are interested in details (a large, multi-threaded stack trace).
Comment on attachment 397057 [details] [diff] [review] patch v1.1 Requesting approval1.9.2. This patch fixes a crash in Adobe Flash Player on Fedora 11. This patch has been in mozilla-central since 2009-08-27. This patch builds the NSS library libfreebl3.so in the same way it is built in Fedora 11, so that our libfreebl3.so can replace the system libfreebl3.so on Fedora 11.
Using Firefox 3.6.pre builds I don't crash on 32 flash sites, and only crash on one specific flash site using 64 bit firefox + 64 bit flash (separate bug I believe). According to my testing, this bugfix works well. After talking to the NSS team, we'd like to propose this bugfix for the stable Firefox 3.5.x branch.
FYI, https://fedoraproject.org/wiki/Mozilla_NSS_Conflict Also various explaining comments have been added in bug 497251 and https://bugzilla.redhat.com/show_bug.cgi?id=505365
Comment on attachment 397057 [details] [diff] [review] patch v1.1 Requesting approval for stable 1.9.1 branch for Firefox 3.5.x This patch affects ONLY Linux. It enables an additional private interface (in libfreebl3.so) that is accessed by the glibc library. This patch will benefit any distributions (and fix bug 497251) that will use a newer glibc library, requiring this additional interface. (It has also the effect that libfreebl3.so will have fewer link time dependences to other nspr/nss libraries, but that's irrelevant for Mozilla software.) This patch does NOT remove any interface, nor change any interface provided by libfreebl3.so required by Mozilla.
(In reply to comment #19) > This patch will benefit any distributions (and fix bug 497251) that will use a > newer glibc library, requiring this additional interface. FTR, that is those that build newer glibc with --enable-nss-crypt. http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=ff886b82a2b65758950bdb4687cf5a1238f697a1
BTW, a TryServer build of Mozilla 1.9.1 with this patch applied is available at: https://email@example.com/ It works for me on Fedora 11 and Ubuntu 9.10
Comment on attachment 397057 [details] [diff] [review] patch v1.1 only a few hours to 184.108.40.206 code-freeze -- if you can squeeze it in then approved for 220.127.116.11, a=dveditz for release-drivers. Otherwise it'll have to wait for 18.104.22.168
Comment on attachment 397057 [details] [diff] [review] patch v1.1 I pushed this patch and the companion patch to mozilla-1.9.1 in changeset 48a9ca3ec69e: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/48a9ca3ec69e