646150 - Firefox-4.0 "segmentation fault" crash on certain sites

Status: RESOLVED DUPLICATE of bug 682625

(Core Graveyard :: Plug-ins, defect)

Description

[Alex]

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
2.6.37.3
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

Comment 1

[Alex]

Attachment: Crash within a GDB session (firefox -g)

Comment 2

[Matthias Versen [:Matti]]

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

Comment 3

[Alex]

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

Comment 4

[Alex]

Attachment: Crash (segmentation fault) within a GDB session WITH backtrace

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

Comment 5

[Alex]

As per your request,
"We need a backtrace with debug symbols"

Comment 6

[Matthias Versen [:Matti]]

Thank you !

Program received signal SIGSEGV, Segmentation fault.
0xb718b6b7 in mozilla::plugins::PluginInstanceParent::BackgroundDescriptor

Comment 7

[Karl Tomlinson (:karlt)]

Alex, does "xdpyinfo | grep RENDER" show anything?

Comment 8

[Alex]

[]$ 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
 ...

Comment 9

[Karl Tomlinson (:karlt)]

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.

Comment 10

[Karl Tomlinson (:karlt)]

(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.

Comment 11

[Karl Tomlinson (:karlt)]

(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.

Comment 12

[Alex]

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

Comment 13

[Alex]

Attachment: xdpyinfo -ext RENDER

Comment 14

[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 15

[Karl Tomlinson (:karlt)]

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.

Comment 16

[Karl Tomlinson (:karlt)]

(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.

Comment 17

[Karl Tomlinson (:karlt)]

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/

Comment 18

[Alex]

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

Comment 19

[Karl Tomlinson (:karlt)]

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.

Comment 20

[Karl Tomlinson (:karlt)]

I'm still not clear what caused this situation, but I expect it will be fixed by the changes in bug 682625.