Closed Bug 123695 Opened 24 years ago Closed 23 years ago

Access Violations on OpenVMS

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
DEC
OpenVMS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: Malmberg, Assigned: asa)

References

Details

Attachments

(1 file)

Test program
976 bytes, text/plain
Details
I am recording stack dumps under this bug that may not be reproducable. Hopefully the stackdump will help find some bug. This crash occurred while I was changing focus from one window to another. You have no mail. %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000006AF0000, PC=FFFFFFFF807D33FC, PS=0000001B %TRACE-F-TRACEBACK, symbolic stack dump follows image module routine line rel PC abs PC 0 FFFFFFFF807D33FC FFFFFFFF807D33FC 0 FFFFFFFF807D17DC FFFFFFFF807D17DC 0 FFFFFFFF807D3A88 FFFFFFFF807D3A88 LIBGDK GDKREGION gdk_regions_subtract 15906 0000000000000B60 00000000004E6A50 LIBGFX_GTK NSREGIONGTK Subtract 53982 0000000000000C0C 000000000253DF9C LIBGKVIEW NSVIEWMANAGER OptimizeDisplayList 53256 000000000000A4B4 0000000002F73984 LIBGKVIEW NSVIEWMANAGER RenderViews 51028 00000000000043A8 0000000002F6D878 LIBGKVIEW NSVIEWMANAGER Refresh 50643 0000000000002DB8 0000000002F6C288 LIBGKVIEW NSVIEWMANAGER DispatchEvent 51719 0000000000006DE8 0000000002F702B8 LIBGKVIEW NSVIEW HandleEvent 58428 00000000000002D4 0000000002F5E2D4 LIBWIDGET_GTK NSWIDGET DispatchEvent 84060 0000000000003E14 0000000000FDFEB4 LIBWIDGET_GTK NSWIDGET DispatchWindowEvent 83951 0000000000003C88 0000000000FDFD28 LIBWIDGET_GTK NSWINDOW DoPaint 107308 0000000000002724 0000000000FE5D04 LIBWIDGET_GTK NSWINDOW Update 107354 00000000000029BC 0000000000FE5F9C LIBWIDGET_GTK NSWINDOW UpdateIdle 107222 000000000000250C 0000000000FE5AEC LIBGLIB GMAIN g_main_dispatch 19215 0000000000000B80 0000000000423FD0 LIBGLIB GMAIN g_main_iterate 19436 000000000000132C 000000000042477C LIBGLIB GMAIN g_main_run 19494 0000000000001548 0000000000424998 LIBGTK GTKMAIN gtk_main 20700 0000000000000A58 00000000006A1A58 LIBWIDGET_GTK NSAPPSHELL Run 80209 00000000000014D4 0000000000FC7574 MOZILLA-BIN NSAPPRUNNER main1 117986 0000000000008FF8 0000000000038FF8 MOZILLA-BIN NSAPPRUNNER main 118312 0000000000009CE8 0000000000039CE8 MOZILLA-BIN NSAPPRUNNER __MAIN 0 0000000000000070 0000000000030070 PTHREAD$RTL 0 0000000000037540 000000007BCEB540 PTHREAD$RTL 0 00000000000183E4 000000007BCCC3E4 0 FFFFFFFF802553D4 FFFFFFFF802553D4 EAGLE> @sys$common:[mozilla]mozilla.com Starting mozilla-bin... You have no mail.
John, I'm not sure what can be done with occasional, non-reproducable, random crashes. Its certainly worth posting them here in case someone can see a pattern emerging, but to be honest I don't hold out much hope. Chances are when they do get fixed it'll be a result of some other bug fixes and we'll never even know.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Well, it is either post them or ignore them. The crashdumps might give a clue to others that are having problems. I have tried to search the bugzilla database before posting, but I can not seem to guess the right keywords. -John
without a reproducible crash this report isn't going anywhere. Are you able to reproduce this crash with any consistency?
Status: ASSIGNED → NEW
The reason that I am posting these unreproducable access violations is that it may be useful in finding the underlying bug. It also may provide additional information should others encounter the same bug or one that is related. An access violation can only occur from a bug in the program where it tries to access memory that it does not currently have access to. I am not sure, but I think the UNIX term is a segfault. This may be from a status value from a procedure call not being checked, and the data being assumed valid, or an uninitialized variable. In many cases inspection of the source in the area where the access violation occurred, especially with structured code can finger the true cause of the problem. That is why all access violations, even ones that can not be reproduced should always be reported as bugs. And also why at least a minimal investigation on them should be done. I do not know about other platforms, On OpenVMS, an access violation usually provices a good enough program stack dump that in many times has all the information needed to positively identify the bug. The program stack dump identifies the line from the OpenVMS Compaq C compiler that the error occured on, and usually this will show a pointer variable or an array index being referenced. From there it is usually a case of seeing if there is any way a bad value could be put in the pointer or the array index.
This access violation occured while I was composing a plain text e-mail reply. Mozilla 0.9.8 Mozilla/5.0 (X11; U; OpenVMS COMPAQ_AlphaServer_DS10_466_MHz; en-US; rv:0.9.8) Gecko/20020202 Starting mozilla-bin... %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000006E4 0000, PC=FFFFFFFF80BD33FC, PS=0000001B %TRACE-F-TRACEBACK, symbolic stack dump follows image module routine line rel PC abs PC 0 FFFFFFFF80BD33FC FFFFFFFF80BD33FC 0 FFFFFFFF80BD17DC FFFFFFFF80BD17DC 0 FFFFFFFF80BD3A88 FFFFFFFF80BD3A88 LIBGDK GDKREGION gdk_regions_subtract 15916 0000000000000B60 000000000297EA60 MOZILLA-BIN NSREGIONGTK Subtract 54007 0000000000000C0C 0000000000FEF31C MOZILLA-BIN NSVIEWMANAGER OptimizeDisplayList 54598 000000000000A204 00000000010DFA24 MOZILLA-BIN NSVIEWMANAGER RenderViews 52537 0000000000004788 00000000010D9FA8 MOZILLA-BIN NSVIEWMANAGER Refresh 52144 0000000000002E68 00000000010D8688 MOZILLA-BIN NSVIEWMANAGER DispatchEvent 53204 0000000000007160 00000000010DC980 MOZILLA-BIN NSVIEW HandleEvent 58370 00000000000002D4 00000000010E92B4 MOZILLA-BIN NSWIDGET DispatchEvent 84231 0000000000003E34 000000000111DEE4 MOZILLA-BIN NSWIDGET DispatchWindowEvent 84122 0000000000003CA8 000000000111DD58 MOZILLA-BIN NSWINDOW DoPaint 107297 00000000000028B4 00000000010F65F4 MOZILLA-BIN NSWINDOW Update 107343 0000000000002B4C 00000000010F688C MOZILLA-BIN NSWINDOW UpdateIdle 107207 000000000000268C 00000000010F63CC LIBGLIB GMAIN g_main_dispatch 19225 0000000000000B80 00000000028BBFD0 LIBGLIB GMAIN g_main_iterate 19446 000000000000132C 00000000028BC77C LIBGLIB GMAIN g_main_run 19504 0000000000001548 00000000028BC998 LIBGTK GTKMAIN gtk_main 20710 0000000000000A58 0000000002B39A58 MOZILLA-BIN NSAPPSHELL Run 80786 00000000000014D4 00000000010F3834 MOZILLA-BIN NSAPPRUNNER main1 118839 0000000000008C00 0000000000C58C00 MOZILLA-BIN NSAPPRUNNER main 119179 0000000000009908 0000000000C59908 MOZILLA-BIN NSAPPRUNNER __MAIN 0 0000000000000070 0000000000C50070 MOZILLA-BIN 0 000000000235F9B8 000000000236F9B8 PTHREAD$RTL 0 0000000000037540 000000007BCEB540 PTHREAD$RTL 0 00000000000183E4 000000007BCCC3E4 0 FFFFFFFF802553D4 FFFFFFFF802553D4 EAGLE> @sys$common:[mozilla]mozilla Starting mozilla-bin...
Attached file Test program —
John, I wonder if these crashes are caused by problems in your X server. If it happens again, can you check how much VM your X server has. An easy way to do this is to run the attached program (you must run it from the SYSTEM account). In fact, you might want to run it in a spare window anyway - its interesting to watch the server's memory comsumption!
0 remaining out of 100000 at Tue Apr 16 22:44:14 2002 0 remaining out of 100000 at Tue Apr 16 22:44:19 2002 0 remaining out of 100000 at Tue Apr 16 22:44:24 2002 0 remaining out of 100000 at Tue Apr 16 22:44:29 2002 0 remaining out of 100000 at Tue Apr 16 22:44:34 2002 0 remaining out of 100000 at Tue Apr 16 22:44:39 2002 0 remaining out of 100000 at Tue Apr 16 22:44:44 2002 0 remaining out of 100000 at Tue Apr 16 22:44:49 2002 EAGLE> show mem System Memory Resources on 16-APR-2002 21:45:52.22 Physical Memory Usage (pages): Total Free In Use Modified Main Memory (256.00Mb) 32768 1863 29243 1662 Virtual I/O Cache: Total Free In Use Cache Memory (Mb) 3.12 0.00 3.12 Granularity Hint Regions (pages): Total Free In Use Released Execlet code region 1024 0 447 577 Execlet data region 160 0 160 0 S0/S1 Executive data region 510 0 510 0 Resident image code region 1024 0 846 178 Slot Usage (slots): Total Free Resident Swapped Process Entry Slots 100 58 40 2 Balance Set Slots 98 58 38 2 Dynamic Memory Usage: Total Free In Use Largest Nonpaged Dynamic Memory (Mb) 3.90 1.29 2.61 0.86 Paged Dynamic Memory (Mb) 2.26 1.10 1.16 1.09 Lock Manager Dyn Memory (Kb) 496.00 66.00 430.00 Buffer Object Usage (pages): In Use Peak 32-bit System Space Windows (S0/S1) 13 13 64-bit System Space Windows (S2) 0 0 Physical pages locked by buffer objects 13 13 Memory Reservations (pages): Group Reserved In Use Type Total (0 bytes reserved) 0 0 Swap File Usage (8KB pages): Index Free Size DISK$EAGLE:[SYS0.SYSEXE]SWAPFILE.SYS 1 1528 1656 Paging File Usage (8KB pages): Index Free Size DISK$EAGLE:[SYS0.SYSEXE]PAGEFILE.SYS 254 29113 33280 Total committed paging file usage: 26470 Of the physical pages in use, 4621 pages are permanently allocated to OpenVMS.
So this crash appears to be caused by the X server running out of memory? If so this is really a configuration issue, and last week I sent a new release note to our tech writer about the need for increasing the X server's virtual page file size. John, if you haven't seen this crash since bumping up your server's PGFLQUOTA, I'd like to close this bug. Is that OK with you?
Colin, I have still been getting crashes, and unexplained exits. I come home from work, and find that the Mozilla program has exited with out an error message. Sometimes in the morning I find the same condition. It appears that MOZILLA is having problems with network timeouts, and looses resources. The worse the ISP's network becomes, the more often the crashes. Occasionally all windows have frozen, And I have had to exit Mozilla and restart it. The pgflquota for the x-server since the last restart of the X-server has been steadily being used up. Currently 45952 is left.
Please install M1.1 when you get a chance and report back your findings (whether the problem occurs more often, less often, or about the same).
John, are you still having problems (with a recent build)? If not, please close this bug.
Mozilla 1.1 Mozilla/5.0 (X11; U; OpenVMS COMPAQ_AlphaServer_DS10_466_MHz; en-US; rv:1.1) Gecko/20020828 I am still having the following problems: Crashes from quotas being exceeded, and from access violations in plugins that are not handled by Mozilla. Frequently the mail and news client will stop communicating with one of the POP servers I use until I completely exit Mozilla. I am closing this bug as INVALID since the information on it is now to old for use with current builds.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
*** Bug 199933 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: