Ticket #262 (closed defect: fixed)

Opened 3 years ago

Last modified 3 years ago

Marker OT_BREAKPOINT_COPIES uses illegal value type

Reported by: stephan Owned by:
Priority: critical Milestone: OTDT_1.3.0_M4
Component: debug Version: 1.3.0M3
Keywords: Cc:

Description

Class CopyInheritanceBreakpointManager creates markers of type OT_BREAKPOINT_COPIES storing an array of !IJavaLineBreakpoint in order to remember the relation between original and copied breakpoints. This is illegal use of markers, which can only be String, Boolean, Integer.

Similar to #245 this remained undetected in Eclipse 3.4 but throws IllegalArgumentException in Eclipse 3.5.

Thus this mechanism has to be re-written.

User visible effect: it is currently not possible to set a breakpoint in a role that has implicit sub roles.

Change History

Changed 3 years ago by stephan

  • milestone set to OTDT_1.3.0

Changed 3 years ago by stephan

r21659 brings a basic implementation:

  • memoize breakpoints using a simple string encoding (:resourcepath?markerID)*
    • encode in duplicateBreakpoint
    • decode in deleteCopiedBreakpoints
  • try to force installation of breakpoint copies (at the time they are created, the type is not yet installed in the VM) (no noticable effect, yet).
  • class/ifc-distinction:
    • avoid duplicate triggering in installingBreakpoint
    • always create breakpoints for the class part (at all nesting levels)
  • trigger breakpoint copying only when trigger type and breakpoint type match.

Note, that more is still needed to actually install the breakpoint copies into the VM. It looks like JavaStratumLineBreakpoint will be our friend, here.

Also need to consider different orders of creating the breakpoint vs. loading the classes.

Changed 3 years ago by stephan

Improved solution, almost a re-write of CopyInheritanceBreakpointManager is in r21660:

  • remove memento mechanism from previous patch
    • no longer store references to copies in the breakpoint
    • CopyInheritanceBreakpointManager keeps its own mapping from breakpoint markers to breakpoints, since we need access even to breakpoints that have not been installed into any target - for those breakpoints reconstructing the marker from a memento doesn't suffice.
  • support more scenarios:
    • disable/enable breakpoints
      • before/after breakpoint copying took place
        (requires to respect the existing breakpoint's enablement)
      • before/after tsub classes are loaded
        (requires listening to marker changes)
    • multiple debug targets using the same classes
      • install the same breakpoints into different targets at different points in time
      • only completely remove a breakpoint if it is no longer installed in any target
  • no longer manually translate line numbers but use a JavaStratumLineBreakpoint for this task (using this indeed fixed the issue that copied breakpoints were not installed into the VM - see previous comment).
  • added nls-support (currently for two UI-visible messages, only)
  • removed lots of stale code

Changed 3 years ago by stephan

  • status changed from new to closed
  • resolution set to fixed
  • milestone changed from OTDT_1.3.0 to OTDT_1.3.0_M4

JUnit test is in r21662, a patch re PhantomType is in r21661, basic test passes.

Further tests (non-phantom role, role file) are in r21666 including a fixup regarding fully qualified names of role files (see also r21664).

Note: See TracTickets for help on using tickets.