hanche@imf.unit.no (Harald Hanche-Olsen) (10/19/90)
I have here this program that I run on a DN10k, displaying its output via X on a DN3k. I am trying to find out why it crashes. Enter good ole tb: % tb -l Process 4967 (parent 352, group 4967) Time 90/02/06.11:45(MET) Program UID 486432B2.6001BAA4 Status 03010002: process had a fatal error (process manager/process mana ger) In routine diagnostic frame (10050000) status 10050000 (socket manager) Called from diagnostic frame (000C0000) status C0000 (OS/DBUF manager) Called from diagnostic frame (9FD7F160) status 9FD7F160 (window systems) Called from That is some program that crashed in February! After printing the above, tb hangs and must be killed. Now, not having tb is a pain in a certain part of the anatomy that isn't mentioned in polite company. I figure it must be one of its files that's corrupted? Does anybody have any idea what files tb uses, and how they can be repaired or something? It would be most helpful. Not having tb, I decided to run my program in dde instead. However, then the program never gets to the point were it crashed, because first this program, which uses xgks, causes that package to wait for a mouse press. In doing so it calls sigpause(0); and there it's stuck forever! What is happening here - does dde eat all the signals sent to the process or something? Any suggestions? - Harald Hanche-Olsen <hanche@imf.unit.no> Division of Mathematical Sciences The Norwegian Institute of Technology N-7034 Trondheim, NORWAY
rees@pisa.ifs.umich.edu (Jim Rees) (10/19/90)
In article <HANCHE.90Oct18180722@hufsa.imf.unit.no>, hanche@imf.unit.no (Harald Hanche-Olsen) writes:
I have here this program that I run on a DN10k, displaying its output
via X on a DN3k. I am trying to find out why it crashes. Enter good
ole tb:
Your program probably isn't leaving a process dump. The reason tb seems to
hang is that it's trying to resolve a procedure name given a uid, and the
executable file containing that procedure is long gone. Process dumps are
kept in \`node_data/system_logs/proc_dump , which you can remove (and
reboot) if you want to clear out old tracebacks.
Not having tb, I decided to run my program in dde instead. However,
then the program never gets to the point were it crashed, because
first this program, which uses xgks, causes that package to wait for a
mouse press.
It's a bad idea to try to run dde on a program that uses an X display on the
same screen as dde. That's because dde uses dialog/gpr and interacts badly
with X. The way I get around this is to redirect the program I'm trying to
debug to a different display on another node. Maybe someday there will be
a version of dde that uses X.glenn@huxley.huxley.bitstream.com (Glenn P. Parker) (10/19/90)
In article <4d79e09d.1bc5b@pisa.ifs.umich.edu>, rees@pisa.ifs.umich.edu (Jim Rees) writes: > It's a bad idea to try to run dde on a program that uses an X display on the > same screen as dde. That's because dde uses dialog/gpr and interacts badly > with X. The way I get around this is to redirect the program I'm trying to > debug to a different display on another node. Then I guess I've have had remarkable success with using dde on the same display as an X program that I'm debugging. I've found that dde will eventually get hung if I use the same invokation of dde to debug many invokations of a program, but if I restart dde after three or four debugs, I don't get hung. I think it helps that I have 16 Mb, instead of 8 Mb. Anyway, what about all those poor folks that don't have an extra workstation lying around just for debugging? How do you debug when your debugger and your X display are separated by more than 10 feet? If dialog/gpr interactions do prove to be problem, you _can_ run dde in a text-only mode on an xterm. This has the benefit of a slightly shorter startup time, but you (obviously) sacrifice the mouse interface and automatic source display. For simple debugging tasks, I don't find it to be such a great sacrifice (especially when dde screws up the source display half the time, anyway :-). > Maybe someday there will be a version of dde that uses X. There darn well better be! Especially if Apollo intends to support X11R4 in non-shared-mode only. -- Glenn P. Parker glenn@bitstream.com Bitstream, Inc. uunet!huxley!glenn 215 First Street BIX: parker Cambridge, MA 02142-1270
kumorek@apollo.HP.COM (James Kumorek) (10/23/90)
In article <GLENN.90Oct18182144@huxley.huxley.bitstream.com>, glenn@huxley.huxley.bitstream.com (Glenn P. Parker) writes: |> > Maybe someday there will be a version of dde that uses X. |> |> There darn well better be! Especially if Apollo intends to support X11R4 |> in non-shared-mode only. The X user interface for DDE is currently under development, and we hope to release it with the next major release of Domain/OS. Jim Kumorek Apollo Computer, Inc. - A subsidiary of Hewlett Packard kumorek@apollo.hp.com