[27067] in Athena Bugs
Re: sun4 9.4.36: java 1.5.0_06's jdb
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sun Mar 11 00:53:50 2007
From: Greg Hudson <ghudson@mit.edu>
To: John Hawkinson <jhawk@mit.edu>
In-Reply-To: <20070311052110.GR21087@multics.mit.edu>
Content-Type: text/plain
Date: Sun, 11 Mar 2007 00:54:42 -0500
Message-Id: <1173592482.3706.313.camel@error-messages.mit.edu>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Spam-Flag: NO
X-Spam-Score: 0.00
Cc: bugs@mit.edu
Errors-To: bugs-bounces@mit.edu
On Sun, 2007-03-11 at 00:21 -0500, John Hawkinson wrote:
> I gather then, that the behavior of exiting when the app
> exits is somehow expected as well?
That, I don't know. It may just be a poor design choice; jdb is
considered a proof-of-concept app, so they may not have put a whole lot
of thought into it. I don't think we're going to submit an upstream bug
report to argue the issue.
> It does appear part of my problem was expecting an invalid classname
> to cause an error from 'stop'...
The debugger doesn't have any way of knowing that you won't dynamically
load a class named System.out in the future, I think. gdb has very
similar behavior if you try to set a breakpoint in a nonexistent
function, although it asks you if you want to delay the breakpoint
rather than just telling you it's doing so.
It may also be that you can't set breakpoints in natively-implemented
methods. You should be able to set a breakpoint at the call site in
that case.