Closed
Bug 561551
Opened 14 years ago
Closed 13 years ago
X_ChangeProperty: BadWindow fatal error in browser with GTK+-2.20, GdkWindow unexpectedly destroyed
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: jstpierre, Unassigned)
References
Details
Attachments
(3 files)
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
Updated•14 years ago
|
Component: General → Widget: Gtk
Product: Firefox → Core
QA Contact: general → gtk
Reporter | ||
Comment 1•14 years ago
|
||
Reporter | ||
Comment 2•14 years ago
|
||
Reporter | ||
Comment 3•14 years ago
|
||
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•14 years ago
|
||
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?
Blocks: OOPP
Updated•14 years ago
|
Component: Widget: Gtk → Plug-ins
QA Contact: gtk → plugins
Summary: Crash: GdkWindow unexpectedly destroyed → X_ChangeProperty: BadWindow fatal error in browser with GTK+-2.20, GdkWindow unexpectedly destroyed
Updated•14 years ago
|
Attachment #441276 -
Attachment mime type: text/x-log → text/plain
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
Reporter | ||
Comment 6•14 years ago
|
||
Eek... I tried to enable debug symbols in my mozconfig, but linking libxul exhausts my memory.
Comment 7•14 years ago
|
||
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.
Reporter | ||
Comment 8•14 years ago
|
||
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.
Reporter | ||
Comment 9•14 years ago
|
||
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.
Reporter | ||
Comment 10•14 years ago
|
||
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
Updated•14 years ago
|
Attachment #442302 -
Attachment mime type: application/octet-stream → text/plain
Comment 11•14 years ago
|
||
> #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/
Reporter | ||
Comment 12•14 years ago
|
||
What's the difference between latest-mozilla-central and latest-trunk?
Reporter | ||
Comment 13•14 years ago
|
||
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•14 years ago
|
||
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
Updated•14 years ago
|
Attachment #441275 -
Attachment mime type: application/octet-stream → text/plain
Comment 15•14 years ago
|
||
(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•14 years ago
|
||
oh, you should try --disable-libxul + --disable-ipc, that should solve your linking problems.
Reporter | ||
Comment 17•13 years ago
|
||
Closing INVALID because I haven't tested in a while, and I'm no longer on the machine where I was getting crashes.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
Updated•13 years ago
|
Resolution: INVALID → INCOMPLETE
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•