89225 - A lot of windows results in a crash

Status: RESOLVED DUPLICATE of bug 86645

(Core :: Layout, defect)

Description

[Theo Jakobus]

After upgrading to M0.9.2 I get crashes if I use Mozilla heavily:
5 browser windows, 1 e-mail window, 1 news window
$ mozilla
Starting mozilla-bin...
Incorporate message complete.
Y'all got mail!
Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter)
  serial 69 error_code 9 request_code 62 minor_code 0
%CXXL-F-TERMINATE, terminate() or unexpected() called
%TRACE-F-TRACEBACK, symbolic stack dump follows
  image    module    routine             line      rel PC           abs PC
 VMS_SYSLIB                                 0 000000000003150C 000000000011550C
 VMS_SYSLIB                                 0 00000000000335BC 00000000001175BC
----- above condition handler called with exception 004081A4:
%CMA-F-EXIT_THREAD, current thread has been requested to exit
----- end of exception message
                                            0 FFFFFFFF800845DC FFFFFFFF800845DC
 PTHREAD$RTL                                0 0000000000021334 000000007BBE3334
 PTHREAD$RTL                                0 000000000002E7D8 000000007BBF07D8
 PTHREAD$RTL                                0 0000000000045C9C 000000007BC07C9C
                                            0 FFFFFFFF800EC4B4 FFFFFFFF800EC4B4
                                            0 FFFFFFFF83F3E6FC FFFFFFFF83F3E6FC
                                            0 FFFFFFFF805FE3C8 FFFFFFFF805FE3C8
                                            0 FFFFFFFF805FE414 FFFFFFFF805FE414
 LIBGDK  GDK  gdk_x_error               22129 0000000000001470 0000000000499470
 DECW$XLIBSHR                               0 00000000001066D0 00000000006526D0
 DECW$XLIBSHR                               0 000000000010998C 000000000065598C
 DECW$XLIBSHR                               0 0000000000104A78 0000000000650A78
 DECW$XLIBSHR                               0 000000000008DA38 00000000005D9A38
 DECW$XTLIBSHRR5                            0 000000000004F510 0000000001719510
 LIBGTKXTBIN  GTKXTBIN  xt_event_dispatch
                                        28804 00000000000002B4 00000000021F82B4
 LIBGLIB  GMAIN  g_main_dispatch        19215 0000000000000B80 00000000003F1FD0
 LIBGLIB  GMAIN  g_main_iterate         19436 000000000000132C 00000000003F277C
 LIBGLIB  GMAIN  g_main_run             19494 0000000000001548 00000000003F2998
 LIBGTK  GTKMAIN  gtk_main              20700 0000000000000A58 0000000000897A58
 LIBWIDGET_GTK  NSAPPSHELL  Run         75989 0000000000001544 00000000046015E4
 MOZILLA-BIN  NSAPPRUNNER  main1        92563 0000000000008470 0000000000038470
 MOZILLA-BIN  NSAPPRUNNER  main         92866 00000000000090F8 00000000000390F8
 MOZILLA-BIN  NSAPPRUNNER  __MAIN           0 0000000000000070 0000000000030070
 PTHREAD$RTL                                0 00000000000312FC 000000007BBF32FC
 PTHREAD$RTL                                0 0000000000012B48 000000007BBD4B48
                                            0 FFFFFFFF83F3F414 FFFFFFFF83F3F414
%DECthreads bugcheck (version V3.15-267), terminating execution.
% Reason:  lckHandoff:  not owner; lock = 0x000000000096A118, value =
0x0000000000000000, expected =
 0x000000007BBCE6F0
% Running on OpenVMS V7.2-1 on Digital Personal WorkStation , 512Mb; 1 CPUs
% The bugcheck occurred at 04-JUL-2001 14:03:30.24, running image
%  IAF021$DKA0:[SYS0.SYSCOMMON.][MOZILLA]MOZILLA-BIN. in process 000002D9
%  (named "_FTA22:"), under username "JAKOBUS". AST delivery is enabled for all
%  modes; no ASTs active. Upcalls are enabled. Multiple kernel threads are
%  disabled.
% The current thread sequence number is -2, at 0x00991B40
%
Next I analyzed the dump.
$ ANALYZE/PROCESS_DUMP/IMAGE=SYS$COMMON:[MOZILLA]MOZILLA-BIN.;1 MOZILLA-BIN.DMP;1
Condition signalled to take dump:

%RMS-F-DME, dynamic memory exhausted
$
The account has paging file quota:  2000000
The system has 512 MByte

Comment 1

[Keyser Sose]

This looks familiar have to track down what its a dupe of.

Comment 2

[Colin Blake]

I see this myself from time to time on OpenVMS, most notably when I run
the browser buster. I don't think its a VMS-specific bug, it just happens to
occur more on OpenVMS for some reason. There are some similar other bug
reports for sure.

Comment 3

[Colin Blake]

Bug 76505 and bug 76125 both report BadDrawable errors but with different 
request codes. Bug 88741 reports identical error and request codes. The
sequence to produce the error is very different but is it the same underlying
cause?

Comment 4

[Theo Jakobus]

I#ve the feeling that the "crash rate" for M0.9.2 is higher.
I checked the PTHREAD_DUMP.LOG files, but there is no output from the Mozilla
executable, as I remember the message in the terminal window was always a
BadDrawable error.
The analysis of the process dump shows always: dynamic memory exhausted. I'm not
able to get more information from the dump my knowledge of OpenVMS isn't good
enough.

Comment 5

[Colin Blake]

Theo, when ANAL/PROC says:

%RMS-F-DME, dynamic memory exhausted

I think its because ANALYZE is running out of memory. I don't think its
telling you that Mozilla failed because it ran out of memory.

Try ANAL/PROC without the /IMAGE and it will drop you into the DELTA debugger
without any word of a DME condition.

Comment 6

[Keyser Sose]

marking NEW.

Comment 7

[karnaze (gone)]

We need a url and test case.

Comment 8

[Colin Blake]

I don't think its any particular URL. This problem occurs intermittently, after
Mozilla has been used for a while. At least thats how I see it.

The GDK error is the only clue. I'll try and get some more info from a
debug build.

Comment 9

[Colin Blake]

The GDK error is not really a GDK error. GDK establishes an error handler via
a call to XSetErrorHandler, and its this error handler which is getting called
by XLib. So its XLib who is detecting the error. 

I was able to track down where this is coming from, and guess what, its right
where I had to change some code for R5 support. The precise line that generates
the error is the XSync call at 
http://lxr.mozilla.org/seamonkey/source/widget/src/gtkxtbin/gtkxtbin.c#429

Remember, the error is:
  Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter)
    serial 69 error_code 9 request_code 62 minor_code 0
and it only happens occasionally. When running choffmans browser buster I can
get to about 50-150 sites visited before I see this failure.

Is the BadDrawable due to the R5 _XtUnregisterWindow call not doing exactly
the same as the R6 XtUnregisterDrawable call?

The ironic part is that the comment says we need to do the XSync call to 
prevent X errors.

Should I use gdk_error_trap_push/pop to ignore this error?

cc'ing blizzard and pavlov in the hope that the gurus can explain this to me

Comment 10

[Colin Blake]

See also bug 86645 (which I believe is the same bug) and 76505 (which was the
same or similar bug that was occuring on other platforms but a fix was 
provided and it went away on other platforms (but remained on OpenVMS)).

I've been trying a few things:
  - setting core.window to 0 - no difference
  - ignore the error - just get a baddrawable somewhere else later
  - remove the XSync call - just crashes sooner
  - add another XSync call before unregister - no difference

So then I put a printf statement in just before the call to unregister and
guess what, now its EXTREMELY hard to reproduce this problem. The problem does
still happen but its MUCH MUCH less frequent.

So its timing related...

Comment 11

[Colin Blake]

I'm convinced that this is the same problem as reported in bug 86645. Moving
all discussions there.

*** This bug has been marked as a duplicate of 86645 ***