Skip to content
This repository has been archived by the owner. It is now read-only.

Pending requests dependent on loaded classes need to stick around #252

Open
chipsenkbeil opened this issue May 13, 2016 · 1 comment
Open

Pending requests dependent on loaded classes need to stick around #252

chipsenkbeil opened this issue May 13, 2016 · 1 comment

Comments

@chipsenkbeil
Copy link
Contributor

@chipsenkbeil chipsenkbeil commented May 13, 2016

Quote from @greenrd from ensime/ensime-server#1330:

Creating duplicate breakpoints

Also fix a bug in JVM attaching that if a class was already loaded but not one of its
anonymous inner classes, a breakpoint might get set only in the former but not the
latter, whereas if neither were loaded at the start, breakpoints would be set in both.

I believe this is also an issue for the way that pending requests are handled in the debugger api since we removed a pending breakpoint request as soon as it is successfully created once. Investigation, integration test proving issue, and fix are needed for this one.

Since pending requests are handled on startup and whenever a class prepare event is received, it seems even more likely that we could hit this case.

@chipsenkbeil
Copy link
Contributor Author

@chipsenkbeil chipsenkbeil commented Sep 23, 2016

My assumption is that this would involve processing active breakpoints again along with pending each time a new class is loaded. In other words, modifying this method: https://github.com/ensime/scala-debugger/blob/master/scala-debugger-api/src/main/scala/org/scaladebugger/api/virtualmachines/StandardScalaVirtualMachine.scala#L188

I'll have to review the code again, but the idea would be to get a list of active breakpoints that are also associated with that file. From there, we just need to make certain that we don't duplicate requests for classes that have already. This means that we might need to

  1. Keep track of low-level classes tied to a breakpoint (add this association to breakpoint info?)
  2. Create an abstraction that can take an existing breakpoint info and NOT create new requests for any of the existing classes specified; only make new requests for new classes

Could be a good way to learn a bit about the low level API and the profile system since it will touch both.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.