System.Diagnostics.Debugger.Break() causes System.Runtime.InteropServices.COMException

[tommcdon]

Description

Calling System.Diagnostics.Debugger.Break() should cause the debugger to stop by triggering a user breakpoint at the location where the function was called.

Reproduction Steps

Call Debugger.Break() in small C# console app

Expected behavior

Debugger should stop as if it hit a breakpoint when Debugger.Break() is called

Actual behavior

A System.Runtime.InteropServices.COMException is triggered

Regression?

This is a regression in .NET 9 main builds

Known Workarounds

N/A

Configuration

All OS's and Architectures

Other information

DebuggerUserBreakpoint::IsFrameInDebuggerNamespace is checking the Namespace and the Class by converting a UTF8 string into a Unicode string:

runtime/src/coreclr/debug/ee/controller.cpp

Lines 8332 to 8333 in bd84a96

	MAKE_WIDEPTR_FROMUTF8(wszNamespace, szNamespace); // throw
	MAKE_WIDEPTR_FROMUTF8(wszClassName, szClassName);

The MAKE_WIDEPTR_FROMUTF8 macro uses ConvertUtf8_Unicode which was re-written in #96099. The original implementation seemed to accept zero-length strings, but the new one will now throw an exception. I am not sure if ConvertUtf8_Unicode intends to support zero length strings (if yes we should consider updating the function). We can work around this particular issue by avoiding converting zero-length strings in DebuggerUserBreakpoint::IsFrameInDebuggerNamespace.

[ghost]

Tagging subscribers to this area: @thaystg
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Calling System.Diagnostics.Debugger.Break() should cause the debugger to stop by triggering a user breakpoint at the location where the function was called.

Reproduction Steps

Call Debugger.Break() in small C# console app

Expected behavior

Debugger should stop as if it hit a breakpoint when Debugger.Break() is called

Actual behavior

A System.Runtime.InteropServices.COMException is triggered

Regression?

This is a regression in .NET 9 main builds

Known Workarounds

N/A

Configuration

All OS's and Architectures

Other information

DebuggerUserBreakpoint::IsFrameInDebuggerNamespace is checking the Namespace and the Class by converting a UTF8 string into a Unicode string:

runtime/src/coreclr/debug/ee/controller.cpp

Lines 8332 to 8333 in bd84a96

	MAKE_WIDEPTR_FROMUTF8(wszNamespace, szNamespace); // throw
	MAKE_WIDEPTR_FROMUTF8(wszClassName, szClassName);

The MAKE_WIDEPTR_FROMUTF8 macro uses ConvertUtf8_Unicode which was re-written in #9609. The original implementation seemed to accept zero-length strings, but the new one will now throw an exception. I am not sure if ConvertUtf8_Unicode intends to support zero length strings (if yes we should consider updating the function). We can work around this particular issue by avoiding converting zero-length strings in DebuggerUserBreakpoint::IsFrameInDebuggerNamespace.

Author:	tommcdon
Assignees:	-
Labels:	untriaged, area-Debugger-mono
Milestone:	-

[ghost]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Calling System.Diagnostics.Debugger.Break() should cause the debugger to stop by triggering a user breakpoint at the location where the function was called.

Reproduction Steps

Call Debugger.Break() in small C# console app

Expected behavior

Debugger should stop as if it hit a breakpoint when Debugger.Break() is called

Actual behavior

A System.Runtime.InteropServices.COMException is triggered

Regression?

This is a regression in .NET 9 main builds

Known Workarounds

N/A

Configuration

All OS's and Architectures

Other information

DebuggerUserBreakpoint::IsFrameInDebuggerNamespace is checking the Namespace and the Class by converting a UTF8 string into a Unicode string:

runtime/src/coreclr/debug/ee/controller.cpp

Lines 8332 to 8333 in bd84a96

	MAKE_WIDEPTR_FROMUTF8(wszNamespace, szNamespace); // throw
	MAKE_WIDEPTR_FROMUTF8(wszClassName, szClassName);

The MAKE_WIDEPTR_FROMUTF8 macro uses ConvertUtf8_Unicode which was re-written in #9609. The original implementation seemed to accept zero-length strings, but the new one will now throw an exception. I am not sure if ConvertUtf8_Unicode intends to support zero length strings (if yes we should consider updating the function). We can work around this particular issue by avoiding converting zero-length strings in DebuggerUserBreakpoint::IsFrameInDebuggerNamespace.

Author:	tommcdon
Assignees:	-
Labels:	area-Diagnostics-coreclr, untriaged, area-Debugger-mono
Milestone:	-

[tommcdon]

I am not sure if ConvertUtf8_Unicode intends to support zero length strings

@AaronRobinsonMSFT @jkotas Do you know if ConvertUtf8_Unicode (and related functions) should accept zero length strings?
For now I have worked around this particular issue by avoiding converting zero-length strings in DebuggerUserBreakpoint::IsFrameInDebuggerNamespace however I am concerned there are other places in the runtime that make the same assumption.

[AaronRobinsonMSFT]

I think we might want to revert #96099 for now.

/cc @huoyaoyuan

[huoyaoyuan]

Can we add some test to exercise patterns used by debugger?

[AaronRobinsonMSFT]

Can we add some test to exercise patterns used by debugger?

Yep. We'll do that in the updated PR.