Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!sdd.hp.com!ucsd!ucbvax!REMUS.EE.BYU.EDU!jlol
From: jlol@REMUS.EE.BYU.EDU (Jay Lawlor)
Newsgroups: comp.sys.hp
Subject: tracing/setting breakpoints on shared binaries and accross fork(2)
Message-ID: <9010131640.AA14589@ucbvax.Berkeley.EDU>
Date: 13 Oct 90 16:40:18 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: jlol@ee.byu.edu
Lines: 30

>>>>> On 13 Oct 90 05:56:06 GMT, jinx@zurich.ai.mit.edu (Guillermo J. Rozas) said:

GJR> Here's a question and a suggestion for HP-UX kernel and debugger gurus:

GJR> I help develop and maintain a Lisp system (MIT C Scheme).  The people
GJR> in our group are often running the binary for the latest version, and
GJR> occasionally come up with some strange behavior that cannot be
GJR> examined with its internal debugger, but instead requires the use of a
GJR> lower-level tool, like cdb, xdb, adb, or gdb.

GJR> The problem is that typically the binary is being run simultaneously
GJR> by multiple users (our set-up is a 30 client cluster served by an 850)
GJR> and it seems that no debugger allows me to set breakpoints after
GJR> attaching it to the running process.

GJR> Restarting the process is not a viable solution because the process
GJR> often has been running for hours or days and it would take that long
GJR> to reconstruct the current (wedged) state even it the appropriate
GJR> input could be typed from scratch.  The problems are not necessarily
GJR> reproducible either, so being able to debug the existing process is
GJR> crucial.

This seems to work (at least on 300 series):

let 'progA' be the program to be debugged that might be in use by
multiple users.

% cp progA progB

cdb -P <pid of progA> progB