dchan@mozart.steinmetz (10/21/87)
We need some help on our Sun's (SunOS 3.4) when debugging the 1986 Berkeley version of MAGIC (a VLSI layout tool). In particular, when we use dbx to debug some local modifications to MAGIC, we get the error Stopped (tty output) we get the prompt, then type reset (because echo is turned off) fg (because the job is in the background) and then we get the error signal IO (possible input/output) in ioctl at 0xee85c ioctl+6: bcss isatty+0x3c (dbx) When we try it without the debugger, the program runs properly. The normal behavior is to create a new window on the monitor, with a prompt in the original window. This looks like a problem with stdout, fork, and dbx. Can anyone give us a clue as to why this is occuring and how to debug MAGIC without adding a lot of printf statements? Thanks in advance. John Pedicone pedicone@ge-crd.arpa uunet!steinmetz!mozart!pedicone
joey@tessi.UUCP (Joe Pruett) (10/23/87)
This may be way off base, but the info could be useful anyway. (I've only seen this behaviour on Sun OS 3.4 under suntools) If your tty structures (as reported by stty -everything) have tostop set and tabs unset (i.e. -tabs) then you will experience things like you describe whenever you invoke cmdtool or dbxtool. This bug is related to text sub windows (ones with scroll bars and the edit menu). Other tools (such as MAGIC) may trigger the same bug. Look at the output of stty and see if that might be the problem. Good luck. -joey
gwu@VLSI.CS.CMU.EDU (George Wu) (10/23/87)
I would guess that the reason for this lies somewhere along the lines
that Magic tries to do I/O in cbreak mode. Dbx on the other hand wants to use
the normal buffered I/O mode. So of course, a conflict occurs, and dbx gives
up. Playing with the tty status (via reset) only confuses the issue more.
I would suggest you try using the GNU debugger, gdb. While I have never
used this debugger, I've heard many claims from devout users, including the
claim that it handles programs that use raw and cbreak mode programs. It also
reputedly handles large programs better.
And now for my own question. Someone has recently asked me about a black
and white version of Magic. Now I know Magic has a Sun b/w driver, but this
guy's only got b/w IBM RTs. So has anyone does this job, or part of it? Thanks
in advance.
Georgegwu@VLSI.CS.CMU.EDU (George Wu) (10/23/87)
Oops, I forgot to mention that he does have X running on the RTs. So if you've got Magic running under b/w X, let me know. Thanks again. George
perez@devvax.JPL.NASA.GOV (Craig D. Perez) (10/23/87)
In article <217@PT.CS.CMU.EDU> gwu@VLSI.CS.CMU.EDU (George Wu) writes: > > I would guess that the reason for this lies somewhere along the lines >that Magic tries to do I/O in cbreak mode. Dbx on the other hand wants to use >the normal buffered I/O mode. So of course, a conflict occurs, and dbx gives >up. Playing with the tty status (via reset) only confuses the issue more. I have never had trouble with dbx and cbreak mode... dbx runs my program normally when I am debugging. The only reason why I could see I/O problems with dbx is if MAGIC is doing non standard reads and writes in cbreak mode (i.e. playing directly with screen attributes and terminal settings). Craig (Perez@devvax.JPL.NASA.Gov) DISCLAIMER: I'm myself and no one else... This is MY opinion!!! -----------> Please direct flames to me and not the net...
mayo@mustard.Berkeley.EDU.berkeley.edu (Bob Mayo) (10/23/87)
Magic does async IO, so that the background DRC can be interrupted. This
gives rise to the DBX problem mentioned. You can instruct some versions
of DBX to ignore certain signals. There is also an undocumented flag in
Magic ("-D") that causes it to behave a bit differently for debugging
purposes. Either of these will, I think, allow Magic to run under DBX.
--Bob Mayo
ucbvax!mayo
mayo@berkeley.eduguy%gorodish@Sun.COM (Guy Harris) (10/24/87)
> I would guess that the reason for this lies somewhere along the lines > that Magic tries to do I/O in cbreak mode. Dbx on the other hand wants to use > the normal buffered I/O mode. So of course, a conflict occurs, and dbx gives > up. Nope. "dbx", at least on Suns (and I suspect on most, if not all, other machines), has no problem with programs using "cbreak" mode; it will restore the tty modes before prompting for input, if necessary. (It doesn't quite handle *output* modes as smoothly - it resets them *after* it's printed a bunch of stuff.) The problem, as was mentioned elsewhere, is that processes being traced with "ptrace" stop when they receive *any* signal. "dbx" can be told that if the process stops with any of a particular set of signals, it should immediately continue the process; SIGIO is not in the default set of "continue immediately" signals, but can be added to that set with "ignore IO". Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com