broderic@genesis.rutgers.edu (Alfred J. Broderick) (05/30/90)
It seems that all programs that use winopen(3G) (including `wsh`) run in the background but do not show up in the when you type `jobs`. How does this work? Is there any way to debug programs that use winopen with `edge`? Whenever I try to use `edge` to debug a program that uses winopen, my program runs to completion before edge is able to do a "stop at". Any help and explainations will be appreciated. Alfred Broderick broderic@topaz.rutgers.edu -- Alfred++
paquette@cpsc.ucalgary.ca (Trevor Paquette) (05/30/90)
In article <May.29.20.11.19.1990.700@genesis.rutgers.edu>, broderic@genesis.rutgers.edu (Alfred J. Broderick) writes: > > It seems that all programs that use winopen(3G) (including `wsh`) > run in the background but do not show up in the when you type `jobs`. > How does this work? Is there any way to debug programs that use > winopen with `edge`? Whenever I try to use `edge` to debug a program > that uses winopen, my program runs to completion before edge is able > to do a "stop at". Just before your winopen() statement add the foreground() statement. This will fix your 'problem'. ___________________________________________/No man is a failure who has friends Trevor Paquette ICBM:51'03"N/114'05"W|I accept the challange, body and soul, {ubc-cs,utai,alberta}!calgary!paquette|to seek the knowledge of the ones of old paquette@cpsc.ucalgary.ca | - engraved on the Kersa Blade of Esalon
davea@quasar.wpd.sgi.com (David B. Anderson) (05/30/90)
In article <May.29.20.11.19.1990.700@genesis.rutgers.edu> broderic@genesis.rutgers.edu (Alfred J. Broderick) writes: > >It seems that all programs that use winopen(3G) (including `wsh`) >run in the background but do not show up in the when you type `jobs`. >How does this work? Is there any way to debug programs that use >winopen with `edge`? Whenever I try to use `edge` to debug a program >that uses winopen, my program runs to completion before edge is able >to do a "stop at". I am posting because it is possible this is confusing more than one person. (1) ``man foreground'' to learn how to prevent the fork. (2) On programs that fork, do (in the dbx command window) the following on startup: set $promptonfork=1 run myprog (At each fork, dbx will ask if you want to debug the child. Type yes (y) to the fork(2) which will fork the graphics process.) (dbx/edge will show the old and new process id's and will have stopped both processes at the exit of fork(2))) active $lastchild (to make commands apply to the child) (Set breakpoints as usual.) cont You can put the startup commands in a text file and read it in with pi myscript (for example) to avoid repetive typing. (Suggestion: set $pimode=1 ) (``man dbx'' and /usr/lib/dbx.help describe other ways to use $promptonfork). This ends the edge/dbx micro-tutorial Hope this helps. [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ]
robert@texas.esd.sgi.com (Robert Skinner) (05/31/90)
In article <May.29.20.11.19.1990.700@genesis.rutgers.edu>, broderic@genesis.rutgers.edu (Alfred J. Broderick) writes: |> |> It seems that all programs that use winopen(3G) (including `wsh`) |> run in the background but do not show up in the when you type `jobs`. |> How does this work? Is there any way to debug programs that use |> winopen with `edge`? Whenever I try to use `edge` to debug a program |> that uses winopen, my program runs to completion before edge is able |> to do a "stop at". |> |> Any help and explainations will be appreciated. |> |> Alfred Broderick |> broderic@topaz.rutgers.edu |> -- |> Alfred++ by default, winopen does a fork(), creating a running copy of your program, then the original program terminates. Issue the foreground() call before you do any winopen()'s, if this is not what you want. Since this is often useful for debugging, a common trick is to issue the foreground call if the DEBUG environment variable is set, like this: if( getenv( "DEBUG" ) ) foreground(); -- so you don't have to recompile to have it run in the foreground for debugging. Robert Skinner robert@sgi.com "The words of the prophets were written on the subway walls" - Simon & Garfunkel
ciemo@bananapc.wpd.sgi.com (Dave Ciemiewicz) (05/31/90)
In article <May.29.20.11.19.1990.700@genesis.rutgers.edu>, broderic@genesis.rutgers.edu (Alfred J. Broderick) writes: > > It seems that all programs that use winopen(3G) (including `wsh`) > run in the background but do not show up in the when you type `jobs`. > How does this work? Is there any way to debug programs that use > winopen with `edge`? Whenever I try to use `edge` to debug a program > that uses winopen, my program runs to completion before edge is able > to do a "stop at". > > Any help and explainations will be appreciated. > > Alfred Broderick > broderic@topaz.rutgers.edu > -- > Alfred++ winopen() forks a copy of the program in such a way that program is backgrounded. By default, dbx/edge do not stop on the fork system call. Solution 1 ---------- There is a mode in dbx/edge to force this adding the forked child process to your process pool, set $promptonfork=2 You can then click on the newly created child process in the edge window and hit debug to select the child process for debugging. Solution 2 ---------- Another approach is to force a GL program. To do this, use the foreground(3G) call. You might #ifdef DEBUG your code so the foreground call is called when you are debugging. This will prevent the fork and make it easier to debug your app. Solution 3 ---------- A trick for debugging GL apps while in dbx/edge, do the following sequence of steps in dbx or the edge command (dbx) window: stop in main run ccall foreground() cont This manual sequence is equivalent ot hardcoding the foreground(3G) call in your code. If you run your code more than once in the the same debugging session, doing "stop in main" is unnecessary. I have used all three of these techniques and find the second one the easiest to deal with though the third solution is useful in a pinch compared the first solution I offer. --- Ciemo
spl@duck.ncsc.org (Steve Lamont) (05/31/90)
In article <8274@odin.corp.sgi.com> robert@sgi.com writes: >by default, winopen does a fork(), creating a running copy of your >program, then the original program terminates. > >Issue the foreground() call before you do any winopen()'s, if this is >not what you want. Pardon my puzzlement, but what are the comparative advantages of forking or not forking upon winopen()? spl (the p stands for puzzled person) -- Steve Lamont, sciViGuy (919) 248-1120 EMail: spl@ncsc.org NCSC (The other one), Box 12889, Research Triangle Park, NC 27709 "It's not a question of whose habitat it is, it's a question of how hard you hit it." -Douglas Adams, "Hitchhiker's Guide to the Galaxy"
wade@fnord.sgi.com (Wade Olsen) (06/01/90)
In article <2238@speedy.mcnc.org> spl@duck.ncsc.org (Steve Lamont) writes: >Pardon my puzzlement, but what are the comparative advantages of forking or >not forking upon winopen()? Graphics programs that don't fork are a pain because they tie up the shell from which they were invoked (i.e. you get no shell prompt until the graphics program exits). You could just remember to run them in background by appending and ampersand to the invocation line, but this leaves a bad taste in my mouth. Wade ++ Wade Olsen, wade@sgi.com, X1023
spl@duck.ncsc.org (Steve Lamont) (06/04/90)
In article <8315@odin.corp.sgi.com> wade@fnord.sgi.com (Wade Olsen) writes: <In article <2238@speedy.mcnc.org> spl@duck.ncsc.org (Steve Lamont) writes: < <>Pardon my puzzlement, but what are the comparative advantages of forking or <>not forking upon winopen()? < <Graphics programs that don't fork are a pain because they tie up the shell <from which they were invoked (i.e. you get no shell prompt until the graphics <program exits). You could just remember to run them in background by appending <and ampersand to the invocation line, but this leaves a bad taste in my mouth. Hmmm. I just open another window. I usually have about ten windows open anyhow. spl (the p stands for phorked up...) -- Steve Lamont, sciViGuy (919) 248-1120 EMail: spl@ncsc.org NCSC (The other one), Box 12889, Research Triangle Park, NC 27709 "It's not a question of whose habitat it is, it's a question of how hard you hit it." -Douglas Adams, "Hitchhiker's Guide to the Galaxy"
mherman@alias.UUCP (Michael Herman) (06/12/90)
One thing winopen( ) doesn't do is respect stdio file pointers/buffers. It should insure that every buffer is flushed before doing the fork. This is a major nuisance to those who are writing "general-purpose" libraries that expect to be called from SGI GL programs. Michael Herman Director, New Workstation Group