73610 - Mozilla crashes when I use Ctrl-W to close a window

Status: RESOLVED WORKSFORME

(Core :: XUL, defect)

Description

[Pete Flugstad]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17 i686; en-US; 0.8.1) Gecko/20010326
BuildID:    2001032614

When I try and use Ctrl-W to close a browser window, mozilla crashes
and exits completely (segmentation fauilt - stack trace below).  
Selecting File->Close does not generate this behavior.

Note: this is 0.8.1. build

Reproducible: Always
Steps to Reproduce:
1.Start Mozilla
2.Use Ctrl-N to create a new Mozilla window
3.Use Ctrl-W to close new Mozilla Window

Actual Results:  Segmentation Fault.  Here's the stack trace:


Program received signal SIGSEGV, Segmentation fault.
0x405e21c2 in gdk_window_ref () from /usr/lib/libgdk-1.2.so.0
(gdb) where
#0  0x405e21c2 in gdk_window_ref () from /usr/lib/libgdk-1.2.so.0
#1  0x405d248d in gdk_event_copy () from /usr/lib/libgdk-1.2.so.0
#2  0x405d23eb in gdk_event_put () from /usr/lib/libgdk-1.2.so.0
#3  0x404a6e5f in NSGetModule ()
   from /home/pete/mozilla/mozilla-0.8.1/components/libwidget_gtk.so
#4  0x404a72aa in NSGetModule ()
   from /home/pete/mozilla/mozilla-0.8.1/components/libwidget_gtk.so
#5  0x404a700c in NSGetModule ()
   from /home/pete/mozilla/mozilla-0.8.1/components/libwidget_gtk.so
#6  0x405d3b80 in gdk_wm_protocols_filter () from /usr/lib/libgdk-1.2.so.0
#7  0x405ff736 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#8  0x405ffd43 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#9  0x405ffeec in g_main_run () from /usr/lib/libglib-1.2.so.0
#10 0x405555d9 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#11 0x4049f4dc in NSGetModule ()
   from /home/pete/mozilla/mozilla-0.8.1/components/libwidget_gtk.so
#12 0x4037755a in inflate_mask ()
   from /home/pete/mozilla/mozilla-0.8.1/components/libnsappshell.so
#13 0x804e025 in JS_PushArguments ()
#14 0x804e885 in JS_PushArguments ()
#15 0x40256cae in __libc_start_main (main=0x804e758 <JS_PushArguments+12836>, 
    argc=1, argv=0xbffff724, init=0x804b074 <_init>, fini=0x8054b04 <_fini>, 
    rtld_fini=0x4000a4d0 <_dl_fini>, stack_end=0xbffff71c)
    at ../sysdeps/generic/libc-start.c:92


Expected Results:  It closes the window

This one has been around (on my box anyway) for a long time.

Linux Distro is Mandrake 7.1 (glibc-2.1.3).
Kernel is 2.2.17 (SMP)
Hardware is Dual Celerons (Abit BP6) 366@500
(this setup is very stable, 60+ days uptime routinely)
Window Mgr is Fvwm2-2.2.4
xdpyinfo:

[pete@taz ~]$ xdpyinfo
name of display:    unix:0.0
version number:    11.0
vendor string:    Linux Mandrake (XFree86 4.0.1, patch level 28mdk)
vendor release number:    4001
maximum request size:  4194300 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    6
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 8, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 15, bits_per_pixel 16, scanline_pad 32
    depth 16, bits_per_pixel 16, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 255
focus:  window 0x1000002, revert to Parent
number of extensions:    22
    BIG-REQUESTS
    DOUBLE-BUFFER
    DPMS
    Extended-Visual-Information
    FontCache
    LBX
    MIT-SCREEN-SAVER
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    SECURITY
    SHAPE
    SYNC
    TOG-CUP
    XC-APPGROUP
    XC-MISC
    XFree86-Bigfont
    XFree86-Misc
    XFree86-VidModeExtension
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo
default screen number:    0
number of screens:    1

Video card is a TNT2 Ultra.

Comment 1

[timeless]

libwidget?

Comment 2

[Peter Trudelle]

Ctrl-W does nothing for me using today's build on RH 6.1/Gnome/Sawfish.  All I 
get is a log entry: Selection controller interface didn't work!
->Arik

Comment 3

[R.K.Aa.]

i built from CVS at 06:17 today (linux). It doesn't crash but i see an assertion
at times:
Gdk-CRITICAL **: file gdkwindow.c: line 716 (gdk_window_ref): assertion `window
!= NULL' failed.

Comment 4

[R.K.Aa.]

forgot: ctrl+w works fine in spite of the assertion.

Comment 5

[arik devens]

hmm... so using 0.8.1 when you do ctrl-n and create a new window the focus (at
least under sawfish) is placed in the text field, then when you do ctrl-w you
clear the text field and the window doesn't do anything.

is this on purpose? seems like a very strange ui choice to me.

anyway i am building today's as we speak and i'll try to reproduce this with
that and fvwm2 when done.

Comment 6

[arik devens]

so i don't seem to be able to reproduce this on redhat 7.0 using fvwm2 and
either yesterday's build or 0.8.1.

i can ctrl-n, ctrl-w just fine.

i will see about getting a mandrake box to test on.

btw the Selection controller interface didn't work! message happens when you are
focused on in the location entry and hit ctrl-w but there is no text in the
entry.

so on fvwm2 a new mozilla window comes up and the top level window has focus
letting you close it with ctrl-w, on sawfish however the entry has focus and
therefore ctrl-w only clears the text (or does nothing if no text is there, and
prints an error) this seems like a bug.

Comment 7

[Pete Flugstad]

I tried it again, and I do have to select the window to remove 
the focus from the URL text box and put it onto the window, before 
the crash will happen.  I must have been doing that automatically 
before (habit...).

I did a quick experiment.  I ssh'd from a laptop running RedHat 6.1
(kernel 2.2.17) into my Mandrake box, and set the display to export
back to the laptop.  Laptop X11 is XFree86 3.3.5, Window manager 
is fvwm2 2.2.2.  Then I fired up mozilla 0.8.1 again, ctrl-n to 
create new window, select the window, ctrl-w, and sure enough, it 
crashed.

So I can arrange for you to have an account on my box if you want, 
with ssh/scp access?  You can export the display back to your desktop.  
Connection is a 3Mbps cable modem, so it's at the low end for X
display, but it's doable.  It's not like you need to do a lot to
get this to happen.  I've probably got the disk space to do the 
build if you need it (/home has 16GB avail).  Or, you could just
set it up to display on the box here and I can hit the keys for you
as needed.  Contact me via private email and we can arrange this.

Note that if I just hit Ctrl-W to close the window without opening
a new one first (effectively quitting mozilla), no segmentation fault.

Could this have something to do with being SMP and me still using
glibc 2.1.3?  I recall issues in the past with this?

Comment 8

[Pete Flugstad]

I ran a test on a Red Hat 6.1 Laptop (custom kernel 2.2.17).
XFree86 3.3.5, fvwm2 2.2.2

Instead of seeing a crash, I see:

  Gdk-CRITICAL **: file gdkwindow.c: line 716 (gdk_window_ref): assertion
   `window != NULL' failed.

The window goes away, but mozilla keeps running OK.

Comment 9

[Avi Rappoport]

Attachment: MacsBug log showing illegal instruction info

Comment 10

[Avi Rappoport]

I'm getting consistent crashes if I use the File menu Close item.  Version 0.9.3
on Mac OS 9.1 (G4 desktop).  The error is "illegal instruction" and I sent the
Macsbug log already.

Comment 11

[John Morrison]

With respect to the previous comment and attachment, this is a Linux bug, not 
Mac. Let's keep it that way :-/

So, is this still reproducible Pete? Or is it fixed now.

Comment 12

[Pete Flugstad]

As of 0.9.3, I can no longer reproduce this bug.  It may
have gotten fixed earlier, but I haven't had a chance to
keep up on the various snapshots (I did load 0.9.2, but
I don't recall testing for this bug).

Note that this is under Linux kernel 2.4.6 (the initial bug
was under 2.2.17).  I quickly rebooted back to 2.2.17, and
I cannot reproduce it there either.  

Is it worth my time to go back and figure out which snapshot
fixed it?

So, looks like it probably is gone?  Well done!!

Comment 13

[John Morrison]

It's not worth trying to track this down to when it was fixed. There have been 
a number of possibly related fixes that have gone in in the past few months; 
finding "the" fix would be tough. 

Anyways, marking WORKSFORME per your comments. Thanks for following up!