561551 - X_ChangeProperty: BadWindow fatal error in browser with GTK+-2.20, GdkWindow unexpectedly destroyed

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Jasper St. Pierre]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100423 Minefield/3.7a5pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre)

On a custom Firefox, 

Crash:
http://pastebin.mozilla.org/718045

I've seen the gdk_window_get_origin one before in a Firefox that doesn't crash, so that's not the problem.

The browser does actually open up my homepage and the

My mozconfig:
http://pastebin.mozilla.org/718050

Versions:
Arch Linux - Kernel 2.6.33
GTK+ 2.20
X.Org X Server 1.7.6

Reproducible: Always

Steps to Reproduce:
1. Open the browser
2. Watch it crash :P

Comment 1

[Jasper St. Pierre]

Attachment: my mozconfig

Comment 2

[Jasper St. Pierre]

Attachment: the output of Firefox before it crashes

Comment 3

[Jasper St. Pierre]

My homepage is netvibes.com

It crashes even with "firefox -safe-mode"

It seems to not crash if I try something like "firefox google.com". Even if I then browse to netvibes.com from that session, it still survives. If I give it "firefox netvibes.com" or "firefox -safe-mode netvibes.com", it crashes.

And it just crashed after a little while on Google

Comment 4

[Karl Tomlinson (:karlt)]

Do you know why the crashreporter is not being activated?
If you can get the crashreporter to work or attach a debugger can you try running with MOZ_X_SYNC=1 in the environment, please?

Comment 5

[timeless]

karlt: comment 0 indicated it was a custom build. he'll need to use gdb.

https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report#Linux

Comment 6

[Jasper St. Pierre]

Eek... I tried to enable debug symbols in my mozconfig, but linking libxul exhausts my memory.

Comment 7

[Karl Tomlinson (:karlt)]

Tell me about it.  In my experience, 3 GB is only just enough memory.
(A build with -g1 instead of -g in configure.in might use less memory.)

I can't see why I changed the summary of this bug now.  I think the pastebin used to contain "X_ChangeProperty: BadWindow" at the end, but please tell me if I'm wrong.  (I'm guessing the seg fault was in the plugin process, probably because the browser terminated unexpectedly.)

There are other options for getting stacks.  Which option is best depends on where the failure is happening.

First use gdb with your opt build to find which file the crash is happening in.
(You can do this without debug symbols, but gdb will probably not be able to produce much of a stack trace because of -fomit-frame-pointer).  If it is an X_ChangeProperty: BadWindow error, then setting a break point in _XError might be most helpful.

Then, if the crash is happening in a Mozilla file, try submitting a crash report using a build from here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

If the crash is in libX11 or libgtk or libgdk then those libraries might need debug symbols to get a stack with gdb (and either your opt build or a downloaded build).

It may also be interesting to see whether the problem still happens with NO_EM_RESTART=1 and GDK_NATIVE_WINDOWS=1 in the environment.

Comment 8

[Jasper St. Pierre]

bah. It seems that that last line got chopped off. Well, I can't reproduce the crash now. And I couldn't reproduce it with a nightly. I'll update if it happens again, and try these things then.

Comment 9

[Jasper St. Pierre]

Even with -g1, it still exhausts all my memory when linking. This is the command line it uses to do the link, except for the .a filenames and -l flags, which I don't think you need.

c++  -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -Wno-long-long -gstabs+ -g1 -fno-strict-aliasing -fshort-wchar -pthread -pipe  -DDEBUG -D_DEBUG -DDEBUG_jstpierre -DTRACING -g1 -Os -freorder-blocks -fno-reorder-functions -fomit-frame-pointer  -fPIC -shared -Wl,-z,defs -Wl,-h,libxul.so -o libxul.so  nsStaticXULComponents.o nsUnicharUtils.o nsCompressedCharMap.o nsBidiUtils.o nsRDFResource.o     -lpthread -gstabs+ -g1   -Wl,-rpath-link,/home/jstpierre/Source/firefox-pgo-minefield/src/mozilla-central/dist/bin -Wl,-rpath-link,/usr/local/lib  -Wl,--whole-archive

I'll have a gdb trace soon, when it crashes again.

Comment 10

[Jasper St. Pierre]

Attachment: backtrace from gdb without debug symbols

Sorry for the bugspam. Here's the backtrace without debug symbols. It may help to add that I'm using libsydneyaudio configured with pulseaudio. These three commands are how I do that.

sed -i 's/sydney_audio_alsa/sydney_audio_pulseaudio/' media/libsydneyaudio/src/Makefile.in || return 1
sed -i 's/alsa/libpulse/' configure.in || return 1
echo 'pulse/pulseaudio.h' >> config/system-headers

Comment 11

[Karl Tomlinson (:karlt)]

> #0  0xb6e0bf66 in ?? () from /usr/local/lib/firefox-3.7a5pre/libmozjs.so
> #1  0x9c55d1c4 in ?? ()

A crash report from a Mozilla build would be able to unwind that (assuming the Mozilla build also crashes).
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

Comment 12

[Jasper St. Pierre]

What's the difference between latest-mozilla-central and latest-trunk?

Comment 13

[Jasper St. Pierre]

And neither latest-mozilla-central nor latest-trunk crash, but my build does. Should I enable the crash reporter and try building with that?

Comment 14

[timeless]

crash-reporter is only useful if you're using *our* builds.

otherwise, just build --enable-debugger-info-modules / --enable-debug and --disable-strip and use a debugger.

https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report#LInux

Comment 15

[Karl Tomlinson (:karlt)]

(In reply to comment #12)
> What's the difference between latest-mozilla-central and latest-trunk?

They should be the same I hope.

Configuring some swap space may make a debug build possible.

Random guess: --disable-java-xpcom might not be a commonly tested option.

Comment 16

[timeless]

oh, you should try --disable-libxul + --disable-ipc, that should solve your linking problems.

Comment 17

[Jasper St. Pierre]

Closing INVALID because I haven't tested in a while, and I'm no longer on the machine where I was getting crashes.