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
This looks familiar have to track down what its a dupe of.
Assignee: asa → karnaze
Severity: normal → critical
Component: Browser-General → Layout
QA Contact: doronr → petersen
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.
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
We need a url and test case.
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.
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
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...
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 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.