Fix MacOS launch bug when spaces in module names.

[mikem8361]

Shiproom template

Description

The libdbgshim.dylib launch/attach helper had a bug with module names with spaces in them. The Excel (Oded Hanson) ran into this because ship the .NET Core in a sub-directory with a space in the path.

This causes launch (or attach) with VS (VSCode or VS for Mac) to hang..

The fix is to change the vmmap output parsing to include the rest of the line as the module name.

Customer Impact

Without this fix, Excel can not debug their product and an official build is needed to get the dbgshim for insertion into VS vsdbg to fix the problem.

Regression?

No.

Risk

Low.

Link to issue

https://github.com/dotnet/coreclr/issues/20401

[danmoseley]

@dotnet-bot test this please

[danmoseley]

I guess the build is partly broken in this branch at least for arm64

make[2]: *** No rule to make target 'System.Native/CMakeFiles/System.Native.dir/build'.  Stop.
make[2]: Leaving directory '/mnt/j/workspace/dotnet_coreclr/release_2.2/arm64_debug_small_page_size_innerloop_prtest/fx/bin/obj/Linux.arm64.Release/native'
CMakeFiles/Makefile2:181: recipe for target 'System.Native/CMakeFiles/System.Native.dir/all' failed
make[1]: *** [System.Native/CMakeFiles/System.Native.dir/all] Error 2

[Eilon]

Out of curiosity, can the VSIZE RSDNT DIRTY SWAP fields never have an M in there for megabytes? Are they always in kilobytes?

[mikem8361]

As far as I know they are always in KB. This isn't well documented.

[Eilon]

Yeah I couldn't find any info on this (though I also wasn't sure what to search for).

Is it possible to create a test case with an app that has a really large "one of those things" to see what it is? E.g. what if an app has more than 99,999KB of VSIZE? (only 5-digit numbers fit in the table)

[mikem8361]

The arm64 build failures are in the 2.2 branch and nothing to do with my changes. I’m sync’ing and will push a new commit with the latest 2.2 branch just in case it was fixed.

[mikem8361]

To be clear, my change didn’t affect any of that part of the parsing. Just the module name at the end. It has been this way since 1.1.

[jamshedd]

Approved for 2.2

[Eilon]

Is it worth looking into the parsing further? To be clear, I have no background in this at all, just saw something curious.

[mikem8361]

@Eilon you could write up an issue to investigate this more and assign it to me.

[Eilon]

Logged https://github.com/dotnet/coreclr/issues/20568