| Title: | DECWINDOWS 26-JAN-89 to 29-NOV-90 |
| Notice: | See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit |
| Moderator: | STAR::VATNE |
| Created: | Mon Oct 30 1989 |
| Last Modified: | Mon Dec 31 1990 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3726 |
| Total number of notes: | 19516 |
I have been going along fine for a month using my 6-mb VS2000
for little else than running VWSLAT and a few DECterms. I keep
Bookreader and FileView around iconized but rarely bring them up.
Most of my "real work" lately has been done in VWSLAT sessions on our
cluster.
Then I began trying to buld a DW application on my workstation
(Solitaire from DW_EXAMPLES, if you care). And I found myself
hanging the workstation repeatedly.
The exact sequence of events: environment as described above:
1. Start compile-and-link command file on VS.
2. Iconify DECterm doing (1).
3. Read some notes in DECterm running VWSLAT session on cluster
4. Wonder how compile is going, attempt to deiconify DECterm doing (1).
The window will come part of the way up; usually just the WM
decorations, no text in the window, no input focus. And I'm hung.
Can't even log in via my serial port.
So: should I go about gathering more information, and if so, how?
Or is there some tried-and-true incantation or ritual I can perform?
Help, in short...
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 212.1 | This could be CHILD's priority 0 problem | PRNSYS::LOMICKAJ | Jeff Lomicka | Wed Feb 15 1989 14:27 | 13 |
Are you using CHILD release 13, or running VWSLAT from DECW$LOGIN.COM? If so, it's possible that CHILD or even VWSLAT created a DECTerm terminal emulator process (of the form _node::0.0) that's running at priority 0. (This was a bug, of course.) Because the compilation and link is running with lots of computes, the emulator get's none at all. There's an update to CHILD that fixes this. To check, do a SHOW SYSTEM and look for the process name of the form above, and see if it's at priority 0. If so, get a new CHILD. | |||||
| 212.2 | I think it's pagefile overflow. | CIM::KAIRYS | Michael Kairys | Wed Feb 15 1989 16:58 | 31 |
> This could be CHILD's priority 0 problem
From what you say, Jeff, I don't think so. I don't see any such
processes after starting up VWSLAT and starting a session with it.
I do use CHILD to start VWSLAT, but I do so manually, via a FileView
command file.
So, far, I can duplicate the described behavior every time.
I tried the experiment of having a process loged in from the terminal
connected to my serial port. I set that process's priority to 15 and
ran monitor process /topcpu in it while I (1) ran my compile and (2)
horsed around in the VWSLAT session. I learned two things:
(1) the swapper was running at the time of the hang,
(2) it's not just the emulator that's hanging - my priority 15 process
was hung as well.
FLASH - late-breaking news...
I think my problem is that I'm running out of pagefile. I've got a
22,000 block file, but I watched show memory in a loop and saw
available space go down to zero while my compile was running in batch.
I'm running with a rather small WSMAX - 800. I think I'll try
increasing that first, and then try increasing my pagefile size.
I thought 22,000 was a lot, but I started the compile with only 6,000
available.
Any thoughts, anyone?
| |||||
| 212.3 | Known VAXC T3.0-FT3 bug. | CIM::KAIRYS | Michael Kairys | Tue Feb 21 1989 13:55 | 6 |
The end of this little saga is: known bug in VAXC T3.0-FT3 causing memory
leak.
Compiling solitaire.c caused my process to consume over 19,000 virtual
pages and go looking for more.
| |||||