From: Homan, Charles (NE) (Charles.Homan@GDC4S.Com)
Date: Tue Jun 03 2003 - 16:08:30 EDT
Fellow managers:
I have a weird one for you. One of our engineers has noticed that when he
starts a bunch of dtterms on the command line by running "dtterm&" over and
over he eventually gets a warning dialog saying "unable to get pty". Fair
enough - that's what we would expect.
However, when he does the same thing via the CDE GUI (clicking on "This
Host" in the CDE task bar instead of typing "dtterm") he does not get the
same error dialog (or any error in any log I have found) and he gets
significantly fewer dtterms. They just stop appearing: the cursor goes to
the wait state and the globe above the exit button spins, but no window
appears. In my testing, I was able to bring up 19 dtterms (on a semi-loaded
system) using the command line method but only 11 using the GUI method.
The question is: why the difference? I would have thought that the result
would be the same in both cases. Certainly the windows seem exactly the
same, and the process looks to be the same. The engineer also noticed that
certain of the inter-process communication routines he wrote still work when
he runs out of ptys using the command line method, but fail when he can no
longer bring up more dtterms using the GUI. This would tend to indicate
that the GUI method is hogging some resource other than ptys, but I haven't
been able to figure out what. Memory and swap remain high, and I should
still have 8 ptys free (based on the command line test, which I have run
back-to-back-to-back with the GUI test to verify that the numbers remain
consistent.) What else could it be?
I have tried "truss -fp" on the ttsession process in an attempt to debug
this. This is the beginning of the truss when clicking on the "This Host"
button and getting a dtterm:
10401: poll(0xFFBEC0D8, 74, -1) = 1
10401: getmsg(257, 0xFFBEDC24, 0xFFBEDC14, 0xFFBEDC54) = 0
10401: write(9, " s", 1) = 1
10401: poll(0xFFBEE0D0, 0, 0) = 0
10401: poll(0xFFBEC0D8, 74, -1) = 1
10401: getmsg(257, 0xFFBEDC24, 0xFFBEDC14, 0xFFBEDC54) = 0
10401: write(257, "80\0\0E4 >B0 Q\b\0\0\001".., 232) = 232
10401: poll(0xFFBEE0D0, 0, 0) = 0
10401: poll(0xFFBEC0D8, 74, -1) = 1
10401: ioctl(5, I_PEEK, 0xFFBEDE44) = 1
10401: getmsg(5, 0xFFBEDEB0, 0xFFBEDEA0, 0xFFBEDEDC) = 0
10401: open("/dev/tcp", O_RDWR) = 46
10401: fstat64(46, 0xFFBEDC90) = 0
10401: stat64("/dev/pts/55937", 0xFFBEDBF8) Err#2 ENOENT
10401: ioctl(46, I_FIND, "timod") = 0
10401: ioctl(46, I_PUSH, "timod") = 0
10401: ioctl(46, I_STR, 0xFFBEDC70) = 0
10401: ioctl(46, I_STR, 0xFFBEDC70) = 0
10401: ioctl(46, I_FLUSH, FLUSHRW) = 0
10401: fcntl(46, F_DUPFD, 0x00000100) = 291
10401: close(46) = 0
10401: ioctl(291, I_FIND, "timod") = 1
10401: ioctl(291, I_STR, 0xFFBEDC10) = 0
....
and this is everything printed out after a click of the "This Host" button
which fails to bring up a dtterm:
10401: poll(0xFFBEC0D8, 78, -1) = 1
10401: getmsg(257, 0xFFBEDC24, 0xFFBEDC14, 0xFFBEDC54) = 0
10401: write(9, " s", 1) = 1
10401: poll(0xFFBEE0D0, 0, 0) = 0
10401: poll(0xFFBEC0D8, 78, -1) = 1
10401: getmsg(257, 0xFFBEDC24, 0xFFBEDC14, 0xFFBEDC54) = 0
10401: write(257, "80\0\0E4 >B0 PFE\0\0\001".., 232) = 232
10401: poll(0xFFBEE0D0, 0, 0) = 0
10401: poll(0xFFBEC0D8, 78, -1) (sleeping...)
10401: signotifywait() (sleeping...)
10401: lwp_sema_wait(0xFE30DE78) (sleeping...)
10401: lwp_cond_wait(0xFF2E3F08, 0xFF2E3F18, 0xFEFB3C90) (sleeping...)
I can see that where the one that works follows a "poll" with an "ioctl" the
other is following with "signotifywait", but I'm not sure what to make of
that.
The systems are Ultra 2s and 10s running Solaris 7.
Any troubleshooting advice on this would be welcome.
Thanks,
Charles
ObDisclaimer: My views are mine and not those of my employers.
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:26:31 EDT