New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

Projects
None yet
1 participant
@chipsenkbeil
Member

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 chipsenkbeil added the bug label May 13, 2016

@chipsenkbeil chipsenkbeil added this to the Backlog milestone May 13, 2016

@chipsenkbeil chipsenkbeil modified the milestones: v1.1.0, Backlog Jun 20, 2016

@chipsenkbeil chipsenkbeil added the ready label Jun 25, 2016

@chipsenkbeil

This comment has been minimized.

Show comment
Hide comment
@chipsenkbeil

chipsenkbeil Sep 23, 2016

Member

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.

Member

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 join this conversation on GitHub. Already have an account? Sign in to comment