Name: tb29552 Date: 04/01/2002


run this test (run this from your sdk test/com/sun/jdi dir):

  runregress.sh $ss/ws/regressionTestsInWaiting/RedefineLineNumber.sh -no

The test stops at line 18, does a redefine and a next.
The redefine deletes a line (before line 18). Thus, after
the next, jdb should show the location as still being line
18 but the source line should be the one that was originally
19.

Instead, jdb shows the original line 18, eg:

   :
Breakpoint hit: "thread=main", gus1.a4(), line=18 bci=0
18 System.out.println("a4: The next line should not say Ni!"); // @1
breakpoint

main[1] redefine gus1
/net/mmm/export/mmm/ws/hopper-sdk/test/com/sun/jdi/_regtest.solaris-sparc/JTwork/classes//gus1.class.2
main[1] next
> a4: The next line should not say Ni!

Step completed: "thread=main", gus1.a4(), line=18 bci=8
18 System.out.println("a4: The next line should not say Ni!"); // @1
breakpoint

I turned on the -dbgtrace and found that the FE is re-fetching the
line number info after the redefine, and that the new line number info
is correct. And that ShellScaffold.sh is copying the new version of
gus1.java into gus1.java.

It appears that maybe jdb isn't closing/reopening gus1.java at the
redefine in order to get the new version.

What do you think about this? The redefine cmd tells jdb where to find
a new class file but doesn't tell jdb where to find the corresponding
source code file. It seems like jdb should assume that the original
source code file has been modified and do whatever it needs to do
to get the new version.

======================================================================