User-Agent: Opera/9.80 (X11; Linux i686; U; en) Presto/2.7.62 Version/11.01 Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20100101 Firefox/4.0 When "browsing", firefox crashes when you scroll down on the main page of certain sites. I've chosen the most typical and probably one of the most universally known site, "The New York Times" paper, "www.nytimes.com". The tests are run for this site as "home" page. ------------------------------------------------------- (B)LFS i686-pc-linux-gnu 22.214.171.124 Xorg-7.6 glib-2.28.4 gtk+-2.24.3 sqlite-3.7.5 nspr-4.8.7 nss-3.12.9 libpng-1.5.1 +apng cairo-1.10.2 +tee Firefox built from sources, firefox-4.0.source.tar.bz2 MD5sum: 3468a2c463b4fc2788ba621e4b511c30 Reproducible: Always Steps to Reproduce: 1. Access the site (www.nytimes.com) 2. Scroll down (by mouse wheel or scroll bar) 3. Actual Results: Crash (segmentation fault) See attachment with a gdb session (firefox -g) Expected Results: To work normally (i.e., not to crash) .mozconfig . $topsrcdir/browser/config/mozconfig mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../firefox-build-debug mk_add_options MOZ_MAKE_FLAGS="-j4" ac_add_options --prefix=/usr # ac_add_options --disable-accessibility ac_add_options --disable-auto-deps ac_add_options --disable-crashreporter ac_add_options --disable-dbm ac_add_options --disable-gnomevfs ac_add_options --disable-installer ac_add_options --disable-tests ac_add_options --disable-updater ac_add_options --enable-cpp-rtti ac_add_options --enable-default-toolkit=cairo-gtk2 ac_add_options --enable-image-decoders=all ac_add_options --enable-image-encoders=all ac_add_options --enable-jemalloc ac_add_options --enable-official-branding ac_add_options --enable-places ac_add_options --enable-safe-browsing ac_add_options --enable-system-cairo ac_add_options --enable-system-lcms # ac_add_options --enable-system-sqlite ac_add_options --enable-valgrind ac_add_options --enable-libxul ac_add_options --with-java-bin-path=/opt/jdk/bin ac_add_options --with-java-include-path=/opt/jdk/include ac_add_options --with-qtdir=/opt/qt ac_add_options --with-system-bz2 ac_add_options --with-system-jpeg ac_add_options --with-system-nspr ac_add_options --with-system-nss ac_add_options --with-system-png ac_add_options --with-system-zlib ac_add_options --with-x # Debugging options ac_add_options --enable-debugger-info-modules ac_add_options --disable-strip ac_add_options --enable-debug ac_add_options --disable-optimize Debug version built with export CFLAGS="-ggdb -gstabs+" CXXFLAGS="-ggdb -gstabs+" MOZ_DEBUG_SYMBOLS=1 make -f client.mk build make -f client.mk install
We need a backtrace with debug symbols or a crash ID from an official Mozilla.org binary build. https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report
Hi Matti, Please help me here. Both firefox-4.0 and its companion, xulrunner-2.0 are built with debugging ON (as shown in "Debug version built with" section above.) However, all I get is something like, << Program received signal SIGSEGV, Segmentation fault. 0xb718b6b7 in ?? () from /usr/lib/firefox-4.0/libxul.so (gdb) bt #0 0xb718b6b7 in ?? () from /usr/lib/firefox-4.0/libxul.so #1 0xac7f4130 in ?? () #2 0xac7f4130 in ?? () #3 0x00000000 in ?? () (gdb) >> which is obviously unacceptable for what you want in a backtrace. (looks as if the libxul is not built with debugging symbols.) Thank you, -- Alex
The GDB trace is in two parts separated by a dash line (for ease of examination) Part 1: The whole run trace Part 2: The BackTrace
As per your request, "We need a backtrace with debug symbols"
Thank you ! Program received signal SIGSEGV, Segmentation fault. 0xb718b6b7 in mozilla::plugins::PluginInstanceParent::BackgroundDescriptor
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Version: unspecified → 2.0 Branch
Alex, does "xdpyinfo | grep RENDER" show anything?
$ xdpyinfo | grep RENDER RENDER ----------------------------------------------------- A more detailed "info" $ xdpyinfo ... number of extensions: 27 BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS DRI2 GLX Generic Event Extension MIT-SCREEN-SAVER MIT-SHM RANDR RECORD RENDER SGI-GLX SHAPE SYNC X-Resource XC-MISC XFIXES XFree86-DGA XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST XVideo XVideo-MotionCompensation default screen number: 0 number of screens: 1 ...
NS_ABORT_IF_FALSE(mBackground, "Need a background here") is a debug build means that mBackground (and so xsurf) is non-null. I assume xsurf->XRenderFormat() must be null. Do you still have a debug build, Alex? Are you able to "print xsurf->XRenderFormat()" please? mBackground is created from the default visual. I wonder whether the default visual does not have a render format. Can you attach the output from xdpyinfo -ext RENDER, please? It may also be possible that cairo is not providing a render format for the surface created from the visual. I wonder whether --disable-system-cairo might help. I guess we should probably be creating the background from PictStandardRGB24 instead of the default visual.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #9) > I guess we should probably be creating the background from PictStandardRGB24 > instead of the default visual. Or something else on 16-bit systems.
(In reply to comment #9) > I guess we should probably be creating the background from PictStandardRGB24 > instead of the default visual. Hmm. Default visual was chosen because that is what some plugins expect. Maybe XRenderFindVisualFormat(dpy, DefaultVisual) and bail if null.
Hi Karl, I think I still have everything around in good shape (so to speak). Worst case, I'll start a brand new debug session. The problem persists with many other sites, so there shouldn't be any problems :) Just give me a few hours to regroup; I've been in a different zone lately. Thanks, -- Alex
Hi Karl, > Are you able to "print xsurf->XRenderFormat()" please? ... Program received signal SIGSEGV, Segmentation fault. 0xb718b6b7 in mozilla::plugins::PluginInstanceParent::BackgroundDescriptor (this=0xabf0e120) at /usr/src/mozilla-2.0/dom/plugins/PluginInstanceParent.cpp:801 801 xsurf->GetSize()); (gdb) print xsurf->XRenderFormat() [Thread 0xa55fcb70 (LWP 1338) exited] [Thread 0xa6dffb70 (LWP 1335) exited] [Thread 0xa5dfdb70 (LWP 1337) exited] $1 = (._139 *) 0x0 (gdb) > Can you attach the output from xdpyinfo -ext RENDER, please? It is attached. > I wonder whether --disable-system-cairo might help. Are you talking to me? -- Alex
Comment on attachment 527014 [details] xdpyinfo -ext RENDER > DEFAULT Visual id: 0x21 > visual: > visual id: 0x21 > class: TrueColor > depth: 24 planes > available colormap entries: 256 per subfield > red, green, blue masks: 0xff0000, 0xff00, 0xff > significant bits in color specification: 8 bits >RENDER version 0.11 opcode: 148, base error: 158 > pict format: > format id: 0x2a > type: Direct > depth: 24 > alpha: 0 mask 0x0 > red: 16 mask 0xff > green: 8 mask 0xff > blue: 0 mask 0xff > visual format: > visual id: 0x21 > pict format id: 0x2a I don't see anything out of the ordinary here. The surface should have been created with the default visual 0x21, and I would have expected cairo to find the matching pict format 0x2a.
(In reply to comment #14) > > I wonder whether --disable-system-cairo might help. > > Are you talking to me? Yes, can you try building without --enable-system-cairo in the mozconfig please? cairo 10.2 is newer than that which firefox is generally tested against and may have changed behavior.
Or, perhaps simpler than creating another build, would be to download a build from http://releases.mozilla.org/pub/mozilla.org/firefox/releases/latest-4.0/
Hi Karl, > perhaps simpler than creating another build, would be to download a build ... Here, I'm confused: 1. First, no problem to rebuild the original source (without system cairo). Just takes time, but by the way this Bug processing has gone so far, time is not of the essence (make build ~ 25min on this machine, as a guide). NOTE: If you're NOT talking about a pre-built, please ignore the following. 2. If you're talking a pre-built (i.e. some sort of binary release) I'd be highly surprised NOT to work OK (i.e. "testing" it would be a real exercise in futility). It works in Windows (that's important:) and probably in any Linux distro. I've thought the object of the game has been to see why a build from sources (following all the rules, permissions and nono's) behaves so badly on a modern, up-to-date Linux system. BTW, ironically, configure makes a big fuss about needing cairo with "tee"! For a strangely similar, ugly problem, please see Bug 647910. (also, please, read my parting comments on its "duplicate", Bug 612873.) It is worth emphasizing that firefox-3.6.16 (with a patch handling Bug 640850 !) works OK with both "system cairo" and with "javaxpcom". (That bug was caused by gtk, as you would put it, having changed behavior.) Of course, if I played long enough with various (allowed) with's and enable's and a particular set of companion software versions I could always build a binary that works OK and then I'd release it. I wouldn't mind, BTW, if at configure time, various versions, parameters, _ranges_ etc., whichever they might be, are strictly enforced (and specified - see 647910 above). Like in our case, please no "system cairo" (assuming that's the problem). However, forget about real documentation (at this time and age). 3. But wait (as they say in infomercials). If I use the pre-built at the link specified: [/usr/local/downloads]$ ls -l -rw-r--r-- 1 root root 13851051 2011-04-19 19:42 firefox-4.0.tar.bz2 [/usr/local/downloads]$ tar -xf firefox-4.0.tar.bz2 [/usr/local/downloads]$ cd firefox [/usr/local/downloads/firefox]$ ./firefox ./firefox-bin: /usr/X11R6/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /usr/local/downloads/firefox/libxul.so) ! -- Alex
GLIBCXX_3.4.9 is Bug 621704, so sounds like a local build is easier. Most configure options are intended for expects. They tend to be maintained on a "reasonable effort" basis, but we don't have the testing to test all combinations, so things regress. Usually issues with non-default configurations are not prioritized highly, but patches are accepted. (I'm not familiar with javaxpcom.) In this bug, I'm still at the stage of trying to find out why your build crashes and mine doesn't. If it is triggered by a change in behavior in a newer cairo version then I assume this is something we'll need to fix even for --disable-system-cairo because we will want to update the built-in cairo at some stage.
I'm still not clear what caused this situation, but I expect it will be fixed by the changes in bug 682625.
No longer blocks: 682625
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 682625
You need to log in before you can comment on or make changes to this bug.