Closed Bug 176364 Opened 23 years ago Closed 23 years ago

OpenVMS port; GENERIC_POLL, browser hangs up, nothing goes

Categories

(SeaMonkey :: General, defect)

DEC
OpenVMS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 186023

People

(Reporter: king_george_iii, Assigned: colin)

References

()

Details

User-Agent: Mozilla/5.0 (X11; U; OpenVMS AlphaPC_264DP_500_MHz; en-US; rv:1.2b) Gecko/20021022 Build Identifier: Mozilla/5.0 (X11; U; OpenVMS; en-US; rv:1.2b) Gecko/20021022 DAMMIT, WHY ISN'T OPENVMS IN BUGZILLA'S OPERATING SYSTEM LIST? Mozilla for OpenVMS gets frequently killed thanks to some unix jacket routines (that is how Compaq IPS calls them). Mozilla hangs up or just prints GENERIC_POLL messages. A summary of the most frequent GENERIC_POLL messages: GENERIC_POLL: unknown condition, errno=4 vaxc$errno=2096 GENERIC_POLL: unknown condition, errno=16 vaxc$errno=708 GENERIC_POLL: unknown condition, errno=22 vaxc$errno=20 GENERIC_POLL: unknown condition, errno=65535 vaxc$errno=316 GENERIC_POLL: warning, unable to find the bad FDs GENERIC_POLL: warning, expected 1 events but found 2 GENERIC_POLL: warning, expected 2 events but found 3 An old problem, still not fixed. For the IPS folks who do not know how to interprete OpenVMS error codes, these are the messages... May the debugger be with you... 2096 %SYSTEM-W-CANCEL, operation canceled 708 %SYSTEM-F-DEVACTIVE, device is active 20 %SYSTEM-F-BADPARAM, bad parameter value 316 %SYSTEM-F-IVCHAN, invalid I/O channel How about some real OpenVMS port? No more unix jacket, please! Reproducible: Always Steps to Reproduce: 1. start Mozilla 2. go to a few web sites 3. enjoy the unix jacket Actual Results: Browser hangs. Expected Results: Show the web page.
>DAMMIT, WHY ISN'T OPENVMS IN BUGZILLA'S OPERATING SYSTEM LIST? Uh ? I can see it... CC colin@theblakes.com
OS: other → OpenVMS
Hardware: Other → DEC
Interesting. You're running 1.2b but that version hasn't been released yet for OpenVMS. Anyway, are the GENERIC_POLL messages new to 1.2b, or have they been occuring for a while? Can you run GETINFO.COM (same directory as MOZILLA.COM) and post the output here as a text attachment.
Assignee: asa → colin
Status: UNCONFIRMED → NEW
Ever confirmed: true
1.2b was released for OpenVMS. ftp.mozilla.org /pub/mozilla/releases/mozilla1.2b -rwxr-xr-x 1 22 22 26162176 Oct 23 17:18 mozilla-openvms-alpha-b120.sfx_axpexe The GENERIC_POLL problem is old (see comp.os.vms, reported by other users). However, new GENERIC_POLL messages are showing up with every new Mozilla version. Sorry for missing OpenVMS in the list. It's there. ;-)
Attachment fails, Mozilla hangs. Here is the GETINFO output. $ set noon $ show device g Device Device Error Name Status Count GFA0: Online 0 $ show process /quota 24-OCT-2002 14:26:16.52 User: XXXXXXXX Process ID: XXXXXXXX Node: XXXXXXXX Process name: "XXXXXXXXXXXXXXX" Process Quotas: Account name: XXXXX CPU limit: Infinite Direct I/O limit: 16384 Buffered I/O byte count quota: 130496 Buffered I/O limit: 4096 Timer queue entry quota: 128 Open file quota: 9998 Paging file quota: 2751824 Subprocess quota: 10 Default page fault cluster: 64 AST quota: 4094 Enqueue quota: 9974 Shared file limit: 0 Max detached processes: 0 Max active jobs: 0 Soft CPU Affinity: off $ show display Device: WSA1: [exec] Node: 0 Transport: LOCAL Server: 0 Screen: 0 $ write sys$output f$environment("procedure") SYS$COMMON:[MOZILLA]GETINFO.COM;1 $ show log /ful sys$disk,sys$login,tmp,home "SYS$DISK" [super,crelog] = "SYS$COMMON:" (LNM$PROCESS_TABLE) 1 "SYS$COMMON" [exec] = "XXXXXXXX$DKC100:[SYS0.SYSCOMMON.]" [concealed,terminal] (LNM$SYSTEM_TABLE) "SYS$DISK" [exec] = "XXXXXXXX$DKC100:" [concealed,terminal] (LNM$SYSTEM_TABLE) "SYS$LOGIN" [exec] = "XXXXXXXX$DISK1:[XXXXXXXXX]" (LNM$JOB_819AC5C0) %SHOW-S-NOTRAN, no translation for logical name TMP %SHOW-S-NOTRAN, no translation for logical name HOME $ show log /ful decc* (LNM$PROCESS_TABLE) [kernel] [no protection information] "DECC$EXEC_FILEATTR_INHERITANCE" [super] = "TRUE" "DECC$FIXED_LENGTH_SEEK_TO_EOF" [super] = "TRUE" "DECC$STRTOL_ERANGE" [super] = "TRUE" (LNM$JOB_819AC5C0) [kernel] [shareable] [Quota=(3728,4096)] [Protection=(RWCD,RWCD,,)] [Owner=[XXXXX,XXXXXXXX]] (LNM$GROUP_000101) [kernel] [shareable,group] [Protection=(RWCD,R,R,)] [Owner=[XXXXX,*]] (LNM$SYSTEM_TABLE) [kernel] [shareable,system] [Protection=(RWC,RWC,R,R)] [Owner=[SYSTEM]] (LNM$SYSCLUSTER_TABLE) [kernel] [shareable,system] [Protection=(RWC,RWC,R,R)] [Owner=[SYSTEM]] (DECW$LOGICAL_NAMES) [exec] [shareable] [Protection=(RWCD,RWCD,R,R)] [Owner=[SYSTEM]] $ dir sys$login.; %DIRECT-W-NOFILES, no files found $ run sys$common:[syshlp.examples.decw.utils]xdpyinfo.exe name of display: WSA1: version number: 11.0 vendor string: DECWINDOWS DigitalEquipmentCorp. AXP vendor release number: 7003 maximum request size: 65535 longwords (262140 bytes) motion buffer size: 0 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 2 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 keycode range: minimum 8, maximum 255 number of extensions: 13 DEC-Server-Mgmt-Extension ServerManagementExtension SHAPE MIT-SHM XTEST BIG-REQUESTS MIT-SUNDRY-NONSTANDARD MIT-SCREEN-SAVER SYNC AccessX Xie DEC-XTRAP D2DX Extensions default screen number: 0 number of screens: 1 screen #0: dimensions: 1920x1200 pixels (488x305 millimeters) resolution: 100x100 dots per inch depths (2): 1, 16 root window id: 0x26 depth of root window: 16 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x23 default number of colormap cells: 64 preallocated pixels: black 0, white 65535 options: backing-store NO, save-unders YES current input event mask: 0x70003c ButtonPressMask ButtonReleaseMask EnterWindowMask LeaveWindowMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask number of visuals: 2 default visual id: 0x22 visual: visual id: 0x21 class: DirectColor depth: 16 planes size of colormap: 64 entries red, green, blue masks: 0x1f, 0x7e0, 0xf800 significant bits in color specification: 6 bits visual: visual id: 0x22 class: TrueColor depth: 16 planes size of colormap: 64 entries red, green, blue masks: 0x1f, 0x7e0, 0xf800 significant bits in color specification: 6 bits $ show system /noprocess OpenVMS V7.3 on node XXXXXXXX 24-OCT-2002 14:26:16.69 Uptime 22 20:41:19 $ ucx show version Compaq TCP/IP Services for OpenVMS Alpha Version V5.1 - ECO 4 on a AlphaPC 264DP 500 MHz running OpenVMS V7.3 $ type sys$sysroot:[sysmgr]decw$private_server_setup.com $ ! $ ! DECW$PRIVATE_SERVER_SETUP.COM $ ! $ !**************************************************************************** $ !* * $ !* COPYRIGHT (c) 1992 BY * $ !* DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASSACHUSETTS. * $ !* ALL RIGHTS RESERVED. * $ !* * $ !* THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED * $ !* ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE * $ !* INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR ANY OTHER * $ !* COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY * $ !* OTHER PERSON. NO TITLE TO AND OWNERSHIP OF THE SOFTWARE IS HEREBY * $ !* TRANSFERRED. * $ !* * $ !* THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE * $ !* AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL EQUIPMENT * $ !* CORPORATION. * $ !* * $ !* DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF ITS * $ !* SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL. * $ !* * $ !* * $ !**************************************************************************** $ ! $ if P1 .NES. "INIT" then goto FINAL_SETUP_ENTRY $ $ !============================================================================= $ ! $ ! Device Configuration Setup $ ! $ ! This section is used to override any define device configuration that $ ! has been made. It is executed when DECW$DEVICE.COM invokes this command $ ! file with a single parameter "INIT". At this point, all standard video $ ! devices have been loaded and the primary head has been selected (and is $ ! in the symbol DECW$DEVICE). $ ! $ ! The simplest thing that can be done at this point, and the reason for $ ! this call is to select multi-head. This is done by setting the symbol $ ! DECW$MULTI_HEAD to logical True. And this is what the example does. $ ! $ ! This command procedure will be called a second time just prior to $ ! starting the server process for any additional tailoring. At that $ ! time, this command file will begin execution at the FINAL_SETUP_ENTRY $ ! point. $ ! $ ! Setup for multi-head $ ! $ if DECW$DEVICE_COUNT .GT. 1 then DECW$MULTI_HEAD == 1 $ ! $ ! Add any device configuration setup parameters here. $ ! $ exit $ $FINAL_SETUP_ENTRY: $ ! $ ! This command file is called prior to starting the server process. The $ ! configuration has been determined and all of the defaults have been $ ! set. $ ! $ ! There are a number of DCL symbols which are recognized by the server $ ! startup procedure which can be defined here to modify the default $ ! behavior of the server. $ ! $ ! The following are useful symbols that can be modified by the user and $ ! are defined as follows: $ ! $ ! SYMBOL LIST VALUES DEFAULT $ ! ---------------------------------- ------- --------------- --------------- $ ! DECW$DEVICE YES DEVICE NAME(s) NONE $ ! DECW$MONITOR_DENSITY YES INTEGER 100 $ ! DECW$SERVER_DENSITY NO 75 or 100 100 $ ! DECW$DEFAULT_KEYBOARD_MAP NO STRING NORTH_AMERICAN_LK401AA $ ! DECW$SERVER_TRANSPORTS YES * STRING LOCAL,DECNET $ ! DECW$BUG_COMPATIBILITY NO T/F TRUE $ ! DECW$SERVER_DISABLE_BACKING_STORE YES T/F FALSE $ ! DECW$SERVER_DEFAULT_VISUAL_CLASS YES ** INTEGER NONE $ ! DECW$SERVER_CONNECT_LOG NO T/F FALSE $ ! $ ! All symbols that are LISTS are comma seperated, and each position effects $ ! the device listed in that position in DECW$DEVICE except where noted. If $ ! no value is provided in a position, the first value in the list is used. $ ! $ ! * This list is not per head, but for the entire server. $ ! ** DECW$COLOR is now obselete, use DECW$SERVER_DEFAULT_VISUAL_CLASS $ ! $ ! DECW$DEVICE $ ! $ ! This is the list of screens (heads) for this server. It may be a $ ! single device, or it may be a comma seperated list for each screen. $ ! While it is usually easier to alter this list in the INIT portion $ ! of this command file, it may also be altered here. $ ! $ ! DECW$SERVER_DENSITY $ ! $ ! This symbol controls which fonts should be included in the font path. $ ! The default setting of 100 specifies that the 100dpi fonts are included $ ! in the font path and used by default. Either 75 or 100 can be used $ ! on ANY display. 75dpi will cause windows that are sized based on text $ ! size and the text within them to appear smaller, and 100dpi will cause $ ! them to appear larger. $ ! $ ! There is only one font path. It applies to all screens known to the $ ! server. This symbol also serves as the default for DECW$MONITOR_DENSITY. $ ! $ ! DECW$MONITOR_DENSITY $ ! $ ! The DPI value that will be used inside the server to compute the $ ! size of the screen in mm can be overridden. A 1280x1024 19" screen $ ! is approx. 100dpi, while a 1024x864 19" screen is approx. 75dpi. The $ ! default is currently 100dpi. $ ! $ ! For example: $ ! $ ! DECW$MONITOR_DENSITY == "75,75,100" $ ! $ ! would set the DPI to 75 on heads 0 and 1, and 100 dpi on head 2. $ ! $ ! DECW$DEFAULT_KEYBOARD_MAP $ ! $ ! Allows the default keymap file to be altered. The default is the $ ! NORTH_AMERICAN_LK401AA and can be set to any of the names that appear $ ! in the KEYBOARD option from the session manager option menu. To use a $ ! LK201 use: $ ! $ ! DECW$DEFAULT_KEYBOARD_MAP == "NORTH_AMERICAN_LK201LA" $ ! $ ! DECW$SERVER_TRANSPORTS $ ! $ ! This controls the list of transports that will be available to the $ ! server. The transports provided with DECwindows are: $ ! $ ! LOCAL shared memory transport $ ! DECNET DECnet network transport $ ! TCPIP TCP/IP network transport (requires UCX or equivalent) $ ! LAT Local Area Transport (requires LAT software) $ ! $ ! The default is "DECNET,LOCAL". Additional transports such $ ! as TCPIP or a user-written transport can be added here. $ ! $ ! DECW$BUG_COMPATIBILITY $ ! $ ! In X11R4 and later servers, additional checking was added for unused $ ! bits of certain requests. Some applications have passed -1 (all bits) $ ! and will not work with the strict checking. This symbol allows the $ ! checking to be relaxed so that older X11 applications can run. The $ ! current default is TRUE. $ ! $ ! DECW$SERVER_DISABLE_BACKING_STORE $ ! $ ! It is sometimes useful for performance reasons to disallow backing $ ! store to work in the server. Defining this symbol to be TRUE will $ ! disable the feature. The default is FALSE (backing store is enabled). $ ! $ ! DECW$SERVER_DEFAULT_VISUAL_CLASS $ ! $ ! This symbol overrides the default visual class for each head. The $ ! visual classes are numeric and match the definitions in X.H. They $ ! are: $ ! $ ! 0 = StaticGray $ ! 1 = GrayScale $ ! 2 = StaticColor $ ! 3 = PseudoColor $ ! 4 = TrueColor $ ! 5 = DirectColor $ ! $ ! The default for a specific device type is dependent on the hardware $ ! and is typically PseudoColor for a 8-plane color board, and TrueColor $ ! for a 24-plane option. If you have a monochrome display, you might $ ! consider changing the default visual class to GrayScale to cause colors $ ! to be converted to levels of Gray and output on the Green lead. The $ ! symbol can have multiple values seperated by commas for each head. $ ! For example: $ ! $ ! DECW$SERVER_DEFAULT_VISUAL_CLASS == "3,4,0" $ ! $ ! would specify PseudoColor on head 0, TrueColor on head 1, and StaticGray $ ! on head 2. $ ! $ ! DECW$SERVER_CONNECT_LOG $ ! $ ! This symbol controls whether normal client connect/disconnect messages $ ! get logged to the server error log file or not. By default, all $ ! successful connect/disconnect are not logged. To re-enable these $ ! messages, define this symbol to be TRUE. $ ! $ ! DECW$SERVER_EXTENSIONS $ ! $ ! This symbol identifies which loadable server extensions will be $ ! activated by the server. The loadable extensions provided with $ ! DECwindows are: $ ! $ ! Xie - X Imaging Extension $ ! DEC-XTRAP - X Trap (for testing used by DEC Test Manager) $ ! Multi-Buffering - Multi-buffering (for smooth animation) $ ! D2DX-Extensions - 2D Drawing Extension $ ! $ ! The default is "Xie,DEC-XTRAP,Multi-Buffering". $ ! Use this symbol to remove extensions that will NEVER be used, or to $ ! add user-written or third-party extensions. To avoid activating $ ! X Trap use: $ ! $ ! DECW$SERVER_EXTENSIONS == "Xie,Multi-Buffering,D2DX-Extensions" $ ! $ ! DECW$FONT_SERVERS $ ! $ ! This symbol identifies which font servers will be added to the $ ! end of the server's font path. The syntax for these entries $ ! is: $ ! "tcp/node:7100" for TCP/IP access $ ! "dnet/node::7100" for DECnet access $ ! $ ! The port number (default: 7100) identifies the TCP/IP port $ ! or DECnet object name used to access the font server. Check $ ! the specific font server documentation and with the system $ ! manager of the system on which the font server is running to $ ! get the correct port number. The default for both OpenVMS $ ! and Digital UNIX is 7100. $ ! $ ! DECW$START_FONT_SERVER $ ! $ ! This symbol specifies whether the font server (DECW$XFS) should $ ! be started on this node. The font server can be added to the $ ! server's font path using the DECW$FONT_SERVERS symbol described $ ! above. The fonts known to the font server and the port number used $ ! can be modified by editing the file SYS$MANAGER:DECW$FS_CONFIG.DAT. $ ! To start a font server on this node define DECW$START_FONT_SERVER $ ! to be TRUE. $ ! $ !============================================================================= $ ! $ ! Cluster Common or Standalone Workstation Setup $ ! $ ! This section is used to define private server setup options that all the $ ! workstations in a cluster have in common, or to define the setup options $ ! for a stand-alone workstation. $ ! $ ! Note that if most, but not all, of the workstations have the same setup $ ! option in common, you can define the symbol for the common setup option $ ! in this section, and then redefine the same symbol in the following $ ! workstation-specific section only for those workstations that require a $ ! different setup option. $ ! $ ! Display the graphics configuration... $ ! $ say := write sys$output $ say "Number of screens: ''DECW$DEVICE_COUNT'" $ say "Screen devices and order: ''DECW$DEVICE'" $ $ ! Here are some example setup options that are commented out: $ ! $ ! decw$server_density == "100" $ ! decw$server_default_visual_class == "1" $ ! decw$default_keyboard_map == "US_LK201AA" $ ! decw$server_transports == "DECNET,LOCAL,TCPIP" $ ! decw$server_connect_log == "T" $ ! decw$server_extensions == "Xie,DEC-XTRAP,Multi-Buffering,D2DX-Extensions" $ $!DECW$SERVER_TRANSPORTS=="LOCAL,DECNET,TCPIP,LAT" $DECW$SERVER_TRANSPORTS=="LOCAL,DECNET,TCPIP,LAT" $DECW$BUG_COMPATIBILITY=="FALSE" $DECW$SERVER_DISABLE_BACKING_STORE=="TRUE" $DECW$SERVER_CONNECT_LOG=="TRUE" $!NO MORE Adobe-DPS-Extension, THANKS TO COMPAQ & ADOBE $!DECW$SERVER_EXTENSIONS=="Adobe-DPS-Extension,Xie,DEC-XTRAP,Multi-Buffering,D2DX-Extensions" $DECW$SERVER_EXTENSIONS=="Xie,DEC-XTRAP,Multi-Buffering,D2DX-Extensions" $DECW$SERVER_DEFAULT_VISUAL_CLASS==4 $DECW$XSIZE_IN_PIXELS==1920 $DECW$YSIZE_IN_PIXELS==1200 $DECW$VIRTUAL_PAGES==524288 $DECW$SERVER_WSDEF==65536 $DECW$SERVER_WSQUOTA==262144 $DECW$SERVER_PAGE_FILE==524288 $DECW$SERVER_ENQUEUE_LIMIT==10000 $DEFINE/EXEC/SYSTEM/NOLOG DECW$SERVER_REFRESH_RATE 70 $DEFINE/EXEC/SYSTEM DECW$SERVER_PIXEL_DEPTH 16 $ $IF F$SEARCH("SYS$STARTUP:DECW$EURO_SERVER_SETUP.COM").NES."" $THEN $ @SYS$STARTUP:DECW$EURO_SERVER_SETUP $ENDIF $ $ ! $ !============================================================================= $ ! $ ! Cluster Member Workstation-Specific Setup $ ! $ ! This section is used to define private server setup options depending on $ ! which node in the cluster is executing this command file. This allows a $ ! single DECW$PRIVATE_SERVER_SETUP.COM file to reside in the cluster common $ ! SYS$MANAGER directory and yet define different setup options for any $ ! workstation in the cluster. $ ! $ ! First, replace the definition of node_list with your own list of cluster $ ! node names separated by "/". Next, at the end of this file, add a section $ ! for each node consisting of: a label of the form "DO_NODENAME:" (where $ ! NODENAME is the name of the particular node), followed by DCL commands $ ! that specify the setup options for the particular node, followed by the $ ! DCL command "$ exit". $ ! $ node_list = "" $ ! $ ! An example of a real list might be: $ ! $ ! node_list = "BW75/DUTCH/DUTCH2/UK100/LK201/TCPIP" $ ! $ if node_list .eqs. "" then goto DO_DEFAULT $ node_number = 0 $node_loop: $ node = f$element(node_number, "/", node_list) $ if node .eqs. "/" then goto DO_DEFAULT $ if node .eqs. f$getsyi("NODENAME") then goto DO_'node $ node_number = node_number + 1 $ goto node_loop $ ! $ ! This node is not in the node list. Don't specify any setup options. $ ! $DO_DEFAULT: $ exit $ ! $ ! Workstation with a monochrome 75 dpi monitor. $ ! $DO_BW75: $ decw$server_density == "75" $ decw$server_default_visual_class == "1" $ exit $ ! $ ! Two workstations with Dutch keyboards. $ ! $DO_DUTCH: $DO_DUTCH2: $ decw$default_keyboard_map == "DUTCH_LK201LH_DP" $ exit $ ! $ ! This workstation has a UK keyboard and a 100 dpi monitor. $ ! $DO_UK100: $ decw$server_density == "100" $ decw$default_keyboard_map == "DECW$UK_LK201RE" $ exit $ ! $ ! This system's user wants TCPIP and LOCAL connections to be accepted, $ ! but not DECNET connections. $ ! $DO_TCPIP: $ decw$server_transports == "TCPIP,LOCAL" $ exit $ ! $ ! Workstation with a US LK201 keyboard $ ! $DO_LK201: $ decw$default_keyboard_map == "US_LK201AA" $ exit $ ! $ ! Add the setup options for your nodes here. $ ! $ set noverify DECwindows ident is DW T1.2-6010222 DECwindows server ident is DW V7.3-020426 DECwindows transport ident is DW V7.3-020507 DECwindows xlib ident is DW T1.2-6010222 DECwindows OSF/Motif Toolkit ident is DW T1.2-6010222 DECwindows apps ident is DW V1.2-6010222 DECwindows programming ident is DW T1.2-6010222 351792 remaining out of 524288 at 24-OCT-2002 14:26:16.88
> 1.2b was released for OpenVMS. Just because the kit is present on the server, doesn't mean its released. You need to wait until it appears on the announcement page! Anyway, it was released this morning, and it was the kit which was uploaded last night, so you're all set. The GENERIC_POLL messages are not error messages, just informational messages. They may or may not be related to your hangs.
Thanks for the GETINFO. When do you see it hang? Always on the same page? If so, which? Once hung, how do you unhang it? How many Mozilla windows are up at the time when it hangs? Are you also using mail/news at the time of the hang?
Mozilla always hangs after printing these messages. There is a clear correlation. And that happens so frequently that Mozilla for OpenVMS is basically useless.
The question is, why are you seeing this problem so much when others are not? What is different about your setup/configuration, I wonder. I don't know of anyone else who is finding Mozilla unusable because of this. What are you doing at the time when the messages appear and Mozilla hangs? Surfing? Mail/news? Composer? Chatzilla? How many windows do you have open? How long has Mozilla been up? Are you attempting to connect to servers (http or mail) which are frequently not available? Are you going through a proxy server? Basically any information about when this problem occurs would be useful.
Lowering severity from critical to normal since no one else is having this problem.
Severity: critical → normal
There have been at least two reports through comp.os.vms in the past. They show clearly a crash in routine GENERIC_POLL, module POLL_JACKET, image VMS_JACKETS. Personally I didn't care much because I can also use Mosaic and the GENERIC_POLL hang up does not occur when I use a proxy server. Now the proxy server will be gone soon. In my case Mozilla hangs _without_ proxy server! Some of the error code which I quoted indicate a critical situation, unless you call `bad parameter value' or `invalid I/O channel' normal. I will see if I can come up with some reproduceable scenario.
Severity: normal → critical
At one time poll_jacket used to terminate when it saw that funny poll scenario, and that is probably the "crash" you remember seeing reported. But that was changed a while ago, and I haven't seen or heard of any reports since. Usually that message can be safely ignored. I'm not sure why you are seeing a problem. ECO4 is the most recent ECO for TCP/IP V5.1 I believe.
ECO 4 is the latest update for TCPIP 5.1 and I have installed it. Don't take the lack of complains as a positive sign. IMHO most people have made up their mind about Netscape/Mozilla and support for VMS. Personally I think the entire unix-jacket business is very wrong. When I get a chance (production/development machine...) I will rename the Mozilla directory and reinstall a new version from scratch. In the past I have always updated the releases. Let me know if SYS$COMMON:[MOZILLA...] is the only location where you install Mozilla files. The GENERIC_POLL error messages changed with almost every release. Something is still wrong.
SYS$COMMON:[MOZILLA] is the default install location, and the only place where installation files are copied to. You can install other versions of Mozilla or CSWB) to different locations and run whichever one you wish. All will use the same user profile (or profiles) which hang off of the _MOZILLA directory in your SYS$LOGIN.
> Some of the error code which I quoted indicate a critical situation, unless you > call `bad parameter value' or `invalid I/O channel' normal. Its not normal, no. If everything were normal you wouldn't be reporting a problem! But as a problem report, the severity is normal. An example of a critical problem would be if a significant number of users were completely unable to use Mozilla. This is not the case here and I am lowering the severity back to default severity, or "normal" severity.
Severity: critical → normal
The bug occurres more likely when I open a few new web pages simultaniously in new tabs and switch between the tabs. That works with www.theinquirer.net and www.ebay.com. The GENERIC_POLL error messages are completely gone if a proxy server is in use, but then sometimes new connections won't be established, the browser hangs and eventually may complain about too many redirections. FWIW here is the bugzilla definition of the severity field: Critical - "crashes, loss of data, severe memory leak". The number of people reporting a bug has no impact on the severity. I guess the GENERIC_POLL business doesn't look too nice, which is why we define it as `normal'.
I've been trying on two different systems on the two web sites you mention, and I can not get a poll message to appear. What the heck is it about your environment that is different? You say you usually do NOT use a proxy server, right? www.theinquirer.net requires a flash plugin for its front page. Do you have the flash plugin installed? If not, when the "default plugin" dialog box appears, do you click on CANCEL or just leave the dialog box (maybe hidden behind the main window)?
I have a modified VMS_JACKETS image for you to try. I'd like to see if it makes any difference. Is there somewhere I can ftp it to?
king_george_iii@microsoftsucks.org - please let me know if you can test this new image, and if so, what's the best way for me to get it to you.
Status: NEW → ASSIGNED
Right, the "GENERIC_POLL: unknown condition, errno=16 vaxc$errno=708" messages appear when I do NOT use a proxy server. But when I go through a proxy server, then the browser complains about too many redirections. Unfortunately reducing BYTLM only reduces the probability of hang-ups. It seems you are lucky. :-) Can you use OpenVMS routines to print the error messages, please, let's say use LIB$SIGNAL for the "GENERIC_POLL:" messages and set the severity of the top message to "error" so that we get a traceback? I don't mind to test an image that is compiled with /NOOPTIMIZE/DEBUG=ALL and linked with /TRACEBACK. I can download the file from ftp.mozilla.org. Maybe you could add something like `_debug' to the file name. Just let me know.
The modified VMS_JACKETS.SO can be FTP'd as follows: $ ftp xfer.americas.digital.com When prompted for username specify "anonymous" (case sensitive) When prompted for password specify your email address > cd to_customer > binary > get VMS_JACKETS.SO > quit $ The FTP dropbox is automatically purged every night I believe, so if you don't pick the file up today, I'll have to re-copy. Please let me know if the new image makes any difference.
> Right, the "GENERIC_POLL: unknown condition, errno=16 vaxc$errno=708" > messages appear when I do NOT use a proxy server. But when I go through a > proxy server, then the browser complains about too many redirections. Can you post an example of how the browser complains about too many redirections. I haven't seen this one either. Most of the GENERIC_POLL messages do not contain standard VMS error codes and so it doesn't make sense to signal them in a VMS way. For example, in the message "errno=16 vaxc$errno=708" the 16 is EBUSY and the 708 is irrelevant and should be ignored (vaxc$errno is only meaningful if errno is EVMSERR). But, having said that, the traceback information could prove useful and so that might be worthwhile trying next, after we see if the new VMS_JACKETS image makes any difference.
Sorry, the VMS_JACKETS.SO is already gone. Can you try again, please?
Damn, the filename is lowercase. Sorry about that. Can you try "vms_jackets.so".
Got it. Thanks. Will see what it does and keep you up-to-date.
Before I replaced the image I checked which files were known as installed images (VMS Install utility). VMS_JACKETS.SO was not in the list. None of the Mozilla files were (of course I first got .SO vs. .EXE wrong;-) ! Therefore I checked the startup procedure (would be very nice if it could be called MOZILLA$STARTUP.COM in the future) and it should have done the job. But, I did not call the startup procedure via SYSMAN STARTUP (or SYSTARTUP_VMS.COM). It would be nice if the Mozilla installation procedure (PCSI) would have an option that allows it to add the Mozilla startup procedure via SYSMAN ADD FILE MOZILLA$STARTUP.COM/LOG (great for a cluster configuration, too!). I renamed the original VMS_JACKETS.SO, moved the new one into SYS$COMMON:[MOZILLA] and tried Mozilla again (BYTLM=262144). Again, lots of GENERIC_POLL messages when I accessed www.ebay.com, application hangs. Then I executed the Mozilla startup procedure (as SYSTEM), tried Netscape again and it worked - until I accessed www.theinquirer.net - damn. Neither the shared executables nor the Mozilla executable itself (please, call it MOZILLA.EXE or MOZILLA$foo.EXE) are installed with any privileges. The files are just opened and shared.
No success with the new image and TQELM=512.
I am still trying to reproduce the poll messages, but can not. I see that theinquirer wants a flash player? Have you down loaded the OpenVMS flash player, or are you just clicking on CANCEL repeatedly (or just ignoring the "download flash player" box)?
I don't recall that there is any OpenVMS flash player available or any other OpenVMS plugin. Therefore I play the CANCEL game until my mouse breaks.
Forgot to send you the message for connections through a proxy server. Sorry. Whenever Mozilla starts to print this message it keeps printing it. Alert . / \ Redirection limit for this URL exceeded. Unable to load the requested page. / ! \ -----
Good news (for the bug). I just installed a fresh copy of OpenVMS V7.3-1 on my DS20E, and now I am seeing the problem you describe. As long as I keep going to new sites or purging the cache, its happening fairly frequently. I have another system running V7.3-1 where I've NEVER seen this problem. Very odd. I don't know if its because my DS20 is much faster than the other system or what, but at least now I have something I can work on.
This is very annoying. Let me think out loud in case any of this means anything to anyone. System A is a DS20 dual-processor. This system is my main test system and until today was running V7.1-2 with TCPIP V5.0A1. I never saw this problem. System B is a DPW 500 uni-processor. This system is my secondard test system and is running a very vanilla V7.3-1 with TCPIP V5.3. I never saw the problem on this system either. Today I install OpenVMS V7.3-1 onto a fresh disk on System A. Immediately I start to see the problem reported in this bug. Software configuration is virtually identical between systems A and B, yet B never sees the problem. I changed account quotas on A to match B (only a couple were different). No change. Same with SYSGEN params. No change. I turned off multi-processing on system A. Still no change. To prove I wasn't going insane I rebooted the V7.1-2 disk on system A. Still can't reproduce the problem there. But boot V7.3-1 on system A and I see it immediately. Looked at TCPIP tuning on both systems. They're the same. And neither system is showing any "out of buffer" or similar conditions. If its to do with V7.3-1 or TCPIP V5.3, then why doesn't system B ever see the problem. And if its to do with the speed of the system then why doesn't system A exhibit the problem when its running V7.1-2. I don't get it. I've just produced TCPIP traces from system A and B. Next task is to wade through these to see if I can see what's going on.
I found something interesting in the TCPIP socket tracing. I'm discussing with TCP/IP engineering. I'll report back here once I get an answer.
After thinking about what's going on some more, I reckon the networking issue is a Mozilla problem, and not a problem in TCP/IP. I entered bug 186023 which describes the problem I think is causing all these POLL errors and hangs. Let's see what a mozilla networking expert has to say about my findings.
Depends on: 186023
Good news. I have a workaround for you, I believe. In probing this some more I believe that select() may be mis-behaving, but this only causes a problem when getipnodebyname() is being used in another thread. On OpenVMS getipnodebyname() makes several socket() calls in quick succession, and its when these socket() calls coincide with another thread doing a close() that the problem occurs. This is what I'll discussing with TCPIP engineering. Well, we only use getipnodebyname() if we're on an IPv6 capable platform, and we determine that by "sniffing" at startup time. So (assuming you don't need IPv6 support in Mozilla), all you need to do is cause the sniffing to think that your platform does NOT support IPv6, and then it won't use getipnodebyname(), and then the problem doesn't occur. At least it doesn't for me. Please try this. Edit MOZILLA.COM and find the line: $ define /user GETIPNODEBYNAME TCPIP$GETIPNODEBYNAME Change the definition to something that does NOT exist in the TCPIP shareable, for example: $ define /user GETIPNODEBYNAME TCPIP$GETIPNODEBYNAMEXXX Now try Mozilla. Any better?
Couldn't reach bugzilla, now it's back. Installed 1.3A in the meantime (PCSI file contains A0103 instead of 0103A, thus B0102 follows after A0103 in the list). News group access/NNTP would no longer work. Also had several hand-ups and crashes of the browser/HTTP. Removed TCPIP$GETIPNODEBYNAME, looks much better now, HTTP fine, NNTP fine! Will replace 1.3A with the older 1.2 release ASAP, test it again and keep you posted. Thanks!!!
See bug 189916 - I am making IPv4 the default until we can resolve this issue.
The GENERIC_POLL problem did also materialize with Mozilla 1.3A. Therefore I decided not to reinstall 1.2. Now, after running with the suggested modification for almost 2 weeks I have never again seen this problem. I am sure someone will be able to fix the IPv6 stuff later. Good job, Colin!
Glad to hear its still behaving. I've checked in the "force IPv4 mode by default" fix so that will be in 1.3b.
A change has been requested to TCP/IP Services. For internal tracking purposes the PTR number is 30-5-410
Bug 186023 is being used for tracking the IPv6 problem. Therefore closing this one. *** This bug has been marked as a duplicate of 186023 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.