Closed Bug 4560 Opened 25 years ago Closed 25 years ago

[PP]Closing Compose Window and Editor crashes

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
Other
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 3914

People

(Reporter: esther, Assigned: sspitzer)

Details

RE: Seamonkey win32 April 5 build (99050409)
Hardware:
Description: Closing Compose window (locks up no core dump)
Steps:
1. Run apprunner.exe
2. Select Messenger from the Tasks menu
3. Click the New Msg button to open the Compose window
4. Close the Compose window using the X on the right side of title bar or any of
the other ways to close the window.
5. All other windows lock up, can't use them
Summary: Closing Compose Winod crashes using 4/4/99 build → Closing Compose Window crashes using 4/4/99 build
Summary: Closing Compose Window crashes using 4/4/99 build → Closing Compose Window crashes using 4/5/99 build
build is actually 99040509
Seth or Alec - do you know who this belongs to?  Phil is on vacation Tues/Wed
and I don't want this bug to get "lost".
Assignee: phil → sspitzer
This happened on build 99040615 too.  Reassigning to seth since Phil is out.
Severity: major → critical
Summary: Closing Compose Window crashes using 4/5/99 build → Closing Compose Window crashes
Target Milestone: M4
I think this should be a M4 stopper since after the user composes a message and
sends, he has to close the compose window manually because Send doesn't close
the window for the user.

If anyone disagrees about the M4 state, pls change accordingly.
Phil is not here at this time to triage this bug so I'm going to take the
privilege and do so :-)
Esther let me know if this happens on the builds for today (april 7th) too. I
just sent myself a message on Linux and closed the window and didn't see a
crash. But I'm running my CVS tree and not a release build....
Linux doesn't crash for me either.

Esther, is this a linux bug or Win32?  The bug report sounds like win32, but the
picker says "Linux" and it is assigned to me.

Can you clarify?
Esther says her comment from 4/7 at 10:02 is for Linux.  If you try yesterday's
release build, you should be able to reproduce the problem.

As for the Win32 comment in the original description, Esther thinks she made an
error there.  However, to be on the safe side, she will try this also on today's
Win32 build.
This is OK on Win32 build 99040710 dated April 7, and the April 6 build.  This
is a linux only bug.  Sorry for the misinformtion in the Description.  I will
try this again with the 1st build after 99040709 for linux, then update this
bug.
I'm getting this crash.

Here's the stack trace:

#0  0x40a476a7 in gdk_window_ref ()
#1  0x400e1d9f in nsRenderingContextGTK::Init (this=0x87fc2d8,
aContext=0x884ee80, aWindow=0x87ed9c0) at nsRenderingContextGTK.cpp:136
#2  0x400c3b56 in DeviceContextImpl::InitRenderingContext (this=0x884ee80,
aContext=0x87fc2d8, aWin=0x87ed9c0) at nsDeviceContext.cpp:222
#3  0x400c3a13 in DeviceContextImpl::CreateRenderingContext (this=0x884ee80,
aView=0x87d3430, aContext=@0x886a4c8) at nsDeviceContext.cpp:187
#4  0x405c8a79 in nsCaret::DrawCaret (this=0x886a490) at nsCaret.cpp:449
#5  0x405c8c1d in nsCaret::CaretBlinkCallback (aTimer=0x877d9c8,
aClosure=0x886a490) at nsCaret.cpp:497
#6  0x40157de9 in TimerImpl::FireTimeout (this=0x877d9c8) at nsTimer.cpp:73
#7  0x401582d2 in nsTimerExpired (aCallData=0x877d9c8) at nsTimer.cpp:189
#8  0x40a67c11 in g_timeout_dispatch ()
#9  0x40a66dd2 in g_main_dispatch ()
#10 0x40a673bb in g_main_iterate ()
#11 0x40a67571 in g_main_run ()
#12 0x4098e15b in gtk_main ()
#13 0x400931d8 in nsAppShell::Run (this=0x81420f8) at nsAppShell.cpp:208
#14 0x40017d55 in nsAppShellService::Run (this=0x8126580) at
nsAppShellService.cpp:186
#15 0x804a8cc in main (argc=1, argv=0xbffffa14) at nsAppRunner.cpp:337

After I sent the message, I hit the X in the upper right to close the window.
After I closed the window, I started getting warnings:

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkLayout'

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

Gdk-CRITICAL **: file gdkdraw.c: line 89 (gdk_draw_rectangle): assertion
`drawable != NULL' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkLayout'

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

Gdk-CRITICAL **: file gdkdraw.c: line 89 (gdk_draw_rectangle): assertion
`drawable != NULL' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkLayout'

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

Gdk-CRITICAL **: file gdkdraw.c: line 89 (gdk_draw_rectangle): assertion
`drawable != NULL' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkLayout'

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

Gdk-CRITICAL **: file gdkdraw.c: line 89 (gdk_draw_rectangle): assertion
`drawable != NULL' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkLayout'

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

Gdk-CRITICAL **: file gdkdraw.c: line 89 (gdk_draw_rectangle): assertion
`drawable != NULL' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkLayout'

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

Gdk-CRITICAL **: file gdkdraw.c: line 89 (gdk_draw_rectangle): assertion
`drawable != NULL' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkLayout'

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

Gdk-CRITICAL **: file gdkdraw.c: line 89 (gdk_draw_rectangle): assertion
`drawable != NULL' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkLayout'

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

Gdk-CRITICAL **: file gdkdraw.c: line 89 (gdk_draw_rectangle): assertion
`drawable != NULL' failed.
Timer fired for
'file:////builds/sspitzer/MOZILLA/04.07.1999/14.41/mozilla/dist/bin/res/rdf/sidebar.xul#$223'
Timer fired for
'file:///builds/sspitzer/MOZILLA/04.07.1999/14.41/mozilla/dist/bin/res/mailnews/messenger/threadPane.xul#threadTree'
Timer fired for
'file:///builds/sspitzer/MOZILLA/04.07.1999/14.41/mozilla/dist/bin/res/mailnews/messenger/folderPane.xul#$474'

Gtk-WARNING **: invalid class type `(unknown)' in cast to `GtkLayout'

These warnings look familiar.

Has anyone else seen this before when closing a window?

Syd, do you have an open bug that resembles this?
Didn't someone recently make a "fix" for blinking carets, in the past week
(pavlov?)? Looks like we are in that code when things go wrong.
Didn't someone recently make a "fix" for blinking carets, in the past week
(pavlov?)? Looks like we are in that code when things go wrong.
closing the editor has the same problem.  pavlov thinks it is because the timer
for the caret isn't being destroyed.  After the window is closed via the window
manager, the timer fires and the window is gone, and boom.

to repeat:  this isn't just a compose problem, editor has the same problem.
Summary: Closing Compose Window crashes → Closing Compose Window and Editor crashes
cc: beppe since this is also in the Editor area.
The browser has the same problem -- any of the three windows in apprunner.  It's
basically the same bug as 2503, which reappeared a few days ago -- things aren't
getting cleaned up on the WM_DELETE_WINDOW message.  Syd fixed that quite some
time ago but it reappeared recently.
It is likely something that changed in nsWindow.cpp (in gtk-land). I just pulled
an older version of the file and compiled with the tip of tree and it Works Fine
(tm). I'm rying to identify just what checkin busted my earlier fix.
QA Contact: 4080 → 4098
Stacey - can you keep an eye on this bug?  As soon as it's fixed in M4 and
builds are available, can you verify the fix (at least for mail compose window)?
Thanks.
Sure. (And I do see the crash with today's build.)
To be complete, my comments about it working on 4/7 were unfounded - it was
general window closing that I was referring to, not this mail browser bug. I'm
pulling a build with a fix for 2503 to see if it helps the problem.
FYI.  This isn't a mail only bug.  The editor has the same behaviour.
i looked at it yesterday while i was still in mountain view, and i feel certain
it is the same bug, but if you're rebuilding and such, i'll let you mark it as
duplicate.

thanks syd!
Well, when I try to bring up messenger as described I get a completely blank
window. Perhaps the tree is in flux. Using editor, I get content, and the close
button works, no crash. Same is true actually for the messenger window, but
again, there is no content so I couldn't try out closing the new message dialog.
This bug is a duplicate of 3914, and both are really caused by 4127. What's
happening is that on window close, the entire webshell and pres shell are
being leaked, so nothing knows that the window is going away, and the caret
happily keeps on blinking after the window has been disposed of. This cannot
be fixed until 4127 is fixed.
RE: both win32 (apr08 10;41:00) and Linux 2.0 (1999-04-09-08) build, it does not
crash when closing the Compose window.
Target Milestone: M4 → M5
I still get the crash.  (April 9, 1999, 4:30 build.)

I red 3914 and 4127, and I'm going to later this to M5, as #4127.

When 4127 gets fixed, we'll need to test and see if this bug is fixed.
For me, Syd's fix fixed the problem in the browser and editor, and in the mail
window when I'm not connected to a server.  I'm having trouble navigating
through the new mail prefs to get connected to a server, so I haven't been able
to test anything but a blank folder.
Is syd's fix checked in?  If so, when did he check it in, so I can update, build
and check again.
FYI, this bug does not always cause crashes on Windows, but you sometimes see
a blinking bar on the screen after apprunner quits.
April 9, 2:30 pm.

I just did a cvs update, got syd's latest checkin, rebuilt, and I still get
crash.

I can still make editor and msg compose crash.
What did syd change?
mozilla/widget/src/gtk/nsWindow.cpp

This would only affect Linux.
I fixed my prefs and got a mail window up with a non-blank folder, and I can
still quit the mail window (as well as editor and browser) with the
windowmanager dismiss button and don't see a crash.  I don't know what's
different between Seth's build and mine.  Sujay's optimized build exits the
editor window okay this morning (he says he's marking the other bug as
verified).
My April 09 release build is still crashing there, too.
1)

it doesn't crash every time.  sometimes I just get the warnings over and over:

Gdk-CRITICAL **: file gdkdraw.c: line 89 (gdk_draw_rectangle): assertion
`drawable != NULL' failed.
Gtk-WARNING **: invalid cast from `(unknown)' to `GtkLayout'
Gdk-CRITICAL **: file gdkwindow.c: line 724 (gdk_window_ref): assertion `window
!= NULL' failed.

2)

try typing in the text window (get the cursor started blinking) and then close
via the window manager.  This usually helps make the crash happen.
Yes, you're right.  I see it on mail compose, too -- but not on editor, even if
I get the cursor blinking before I quit.
RE: Linux build (1999-04-09-15)
It consistently had crash when closing the Compose window.
Summary: Closing Compose Window and Editor crashes → [PP]Closing Compose Window and Editor crashes
Why are people wasting time on this bug? As I said above, this bug is a duplicate
of 3914, and both are really caused by 4127. It cannot be fixed until 4127 is
fixed. Don't waste your time.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 3914 ***
Just to complete the audit trail... I was never sure about my fix for handling
window closes 2503 had anything to do with this bug, I simply noted I wasn't
seeing it when I tried with the idea the perhaps there was a relationship
between the two. Looks to me we still have a problem. Part of what seems to be
confusion on this is a comment I made on 04/07/99 19:27 which really applied to
the close window bug I was tracking.
Status: RESOLVED → VERIFIED
Verified dupe.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.