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

Breakpoints aren't hit if tiered jitting recompiled the method before the debugger was attached #14427

Closed
noahfalk opened this Issue Oct 11, 2017 · 0 comments

Comments

Projects
None yet
2 participants
@noahfalk
Member

noahfalk commented Oct 11, 2017

This is related but not identical to #14423.

To repro:

  1. Execute a method Foo in a loop many times so that tiered compilation generates and publishes Tier1 code for it.
  2. Attach Visual Studio to the application
  3. Set a breakpoint in Foo
    The correct behavior is for the debugger to stop at the breakpoint but that won't occur.

The is caused because the runtime's debugger code fails to properly enumerate all the code bodies where the breakpoint needs to be placed. The code at
https://github.com/dotnet/coreclr/blob/master/src/debug/ee/functioninfo.cpp#L2005
only winds up enumerating the Tier0 version of the code but not any other version of the code.

@noahfalk noahfalk self-assigned this Oct 11, 2017

noahfalk added a commit to noahfalk/coreclr that referenced this issue Oct 11, 2017

Fix dotnet#14427
Enumerate all of the jitted instances of a method using the tiered compilation manager

noahfalk added a commit to noahfalk/coreclr that referenced this issue Oct 11, 2017

Fix dotnet#14427
Enumerate all of the jitted instances of a method using the tiered compilation manager

noahfalk added a commit to noahfalk/coreclr that referenced this issue Oct 12, 2017

Fix dotnet#14427
Enumerate all of the jitted instances of a method using the tiered compilation manager

@noahfalk noahfalk closed this in 5dac573 Oct 12, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment