Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Debugger not working on macOS 10.15.x when vmmap hides full path to process modules #42888

Closed
k15tfu opened this issue Sep 30, 2020 · 2 comments · Fixed by #42900
Closed

Debugger not working on macOS 10.15.x when vmmap hides full path to process modules #42888

k15tfu opened this issue Sep 30, 2020 · 2 comments · Fixed by #42900
Assignees
@mikem8361
Labels
area-Diagnostics-coreclr
Milestone
6.0.0

Comments

@k15tfu
Copy link
Contributor

k15tfu commented Sep 30, 2020

Hi! We found that sometimes vmmap that you use for CreateProcessModules (

runtime/src/coreclr/src/pal/src/thread/process.cpp

Line 2860 in d52ee3a

int chars = snprintf(vmmapCommand, sizeof(vmmapCommand), "/usr/bin/vmmap -interleaved %d -wide", dwProcessId);
), can return paths in a "secure" manner, replacing some parts with *.

For example, on my Mac mini with macOS 10.15.7, when I run dotnet from the ~/Downloads directory, I see paths like:

__TEXT                        109ff1000-10a044000        [  332K   332K     0K     0K] r-x/rwx SM=COW          /Users/USER/*/libhostfxr.dylib
__TEXT                        10a04c000-10a091000        [  276K   276K     0K     0K] r-x/rwx SM=COW          /Users/USER/*/libhostpolicy.dylib
__TEXT                        10a09a000-10a526000        [ 4656K  4656K     0K     0K] r-x/rwx SM=COW          /Users/USER/*/libcoreclr.dylib
__TEXT                        10a526000-10a527000        [    4K     4K     4K     0K] r--/rwx SM=COW          /Users/USER/*/libcoreclr.dylib
__TEXT                        10a527000-10a5fa000        [  844K   844K     0K     0K] r-x/rwx SM=COW          /Users/USER/*/libcoreclr.dylib
__TEXT                        10abb0000-10add6000        [ 2200K  2200K     0K     0K] r-x/rwx SM=COW          /Users/USER/*/libclrjit.dylib
__TEXT                        10ae6b000-10ae75000        [   40K    40K     0K     0K] r-x/rwx SM=COW          /Users/USER/*/System.Native.dylib
__TEXT                        10ae79000-10ae82000        [   36K    36K     0K     0K] r-x/rwx SM=COW          /Users/USER/*/System.Globalization.Native.dylib
__TEXT                        112036000-1120c8000        [  584K   568K     0K     0K] r-x/r-x SM=COW          /usr/lib/dyld

In this case, we get CORDBG_E_DEBUG_COMPONENT_MISSING on debugger initialization (

runtime/src/coreclr/src/dlls/dbgshim/dbgshim.cpp

Line 386 in d52ee3a

hr = CORDBG_E_DEBUG_COMPONENT_MISSING;
) because the dbiPath is /Users/USER/*/libmscordbi.dylib and LoadLibraryA cannot find it.

Do you have any objection to using libproc in CreateProcessModules? Looks like iterating over regions using this API gives normal paths, so I'm going to submit a PR. cc @mikem8361 @janvorli @jkotas
@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added area-Diagnostics-coreclr untriaged New issue has not been triaged by the area owner labels Sep 30, 2020
@ghost
Copy link

ghost commented Sep 30, 2020

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

@janvorli
Copy link
Member

cc: @dotnet/dotnet-diag

@k15tfu k15tfu mentioned this issue Sep 30, 2020
Merged
@mikem8361 mikem8361 self-assigned this Sep 30, 2020
@mikem8361 mikem8361 added this to the 6.0.0 milestone Sep 30, 2020
@jeffschwMSFT jeffschwMSFT removed the untriaged New issue has not been triaged by the area owner label Sep 30, 2020
k15tfu added a commit to k15tfu/runtime that referenced this issue Oct 2, 2020
@k15tfu
Get modules information using proc_pidinfo() on macOS
0e4f0a3 
Previously CreateProcessModules() parsed the output of vmmap command to get
modules addresses/paths on macOS, but on some Macs with latest macOS 10.15.6
vmmap hides full paths to some process modules (.dylibs in non-system folders),
replacing some parts with *:
```
__TEXT                 000000010d8bd000-000000010ddce000 [ 5188K  5188K     0K     0K] r-x/rwx SM=COW          /Users/USER/*/libcoreclr.dylib
```

In particular, it breaks the debugger functionality due to invalid path
`/Users/USER/*/libmscordbi.dylib`, and error code
CORDBG_E_DEBUG_COMPONENT_MISSING is returned.

Now we get modules information by iterating over regions using proc_pidinfo()
in CreateProcessModules().

Fixes dotnet#42888
mikem8361 pushed a commit that referenced this issue Oct 12, 2020
@k15tfu
Get modules information using proc_pidinfo() on macOS (#42900)
b099ab3 
Previously CreateProcessModules() parsed the output of vmmap command to get
modules addresses/paths on macOS, but on some Macs with latest macOS 10.15.6
vmmap hides full paths to some process modules (.dylibs in non-system folders),
replacing some parts with *:
```
__TEXT                 000000010d8bd000-000000010ddce000 [ 5188K  5188K     0K     0K] r-x/rwx SM=COW          /Users/USER/*/libcoreclr.dylib
```

In particular, it breaks the debugger functionality due to invalid path
`/Users/USER/*/libmscordbi.dylib`, and error code
CORDBG_E_DEBUG_COMPONENT_MISSING is returned.

Now we get modules information by iterating over regions using proc_pidinfo()
in CreateProcessModules().

Fixes #42888
nehaljwani added a commit to nehaljwani/pycryptodomex-feedstock that referenced this issue Nov 15, 2020
@nehaljwani
Replace use of vmmap with lsof on macOS in run_test.py
a4c8c2c 
In macOS >=10.15.6 vmmap now produces output of the form:
/Users/USER/*/... which hides the absolute paths.

xref: dotnet/runtime#42888
github-actions bot pushed a commit that referenced this issue Nov 16, 2020
@k15tfu
Get modules information using proc_pidinfo() on macOS
bfcfb16 
Previously CreateProcessModules() parsed the output of vmmap command to get
modules addresses/paths on macOS, but on some Macs with latest macOS 10.15.6
vmmap hides full paths to some process modules (.dylibs in non-system folders),
replacing some parts with *:
```
__TEXT                 000000010d8bd000-000000010ddce000 [ 5188K  5188K     0K     0K] r-x/rwx SM=COW          /Users/USER/*/libcoreclr.dylib
```

In particular, it breaks the debugger functionality due to invalid path
`/Users/USER/*/libmscordbi.dylib`, and error code
CORDBG_E_DEBUG_COMPONENT_MISSING is returned.

Now we get modules information by iterating over regions using proc_pidinfo()
in CreateProcessModules().

Fixes #42888
mikem8361 pushed a commit that referenced this issue Nov 18, 2020
@github-actions @k15tfu
Get modules information using proc_pidinfo() on macOS (#44748)
030f593 
Previously CreateProcessModules() parsed the output of vmmap command to get
modules addresses/paths on macOS, but on some Macs with latest macOS 10.15.6
vmmap hides full paths to some process modules (.dylibs in non-system folders),
replacing some parts with *:
```
__TEXT                 000000010d8bd000-000000010ddce000 [ 5188K  5188K     0K     0K] r-x/rwx SM=COW          /Users/USER/*/libcoreclr.dylib
```

In particular, it breaks the debugger functionality due to invalid path
`/Users/USER/*/libmscordbi.dylib`, and error code
CORDBG_E_DEBUG_COMPONENT_MISSING is returned.

Now we get modules information by iterating over regions using proc_pidinfo()
in CreateProcessModules().

Fixes #42888

Co-authored-by: Ilia K <ki.stfu@gmail.com>
@ghost ghost locked as resolved and limited conversation to collaborators Dec 7, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@mikem8361 mikem8361

Labels
area-Diagnostics-coreclr
Projects
None yet
Milestone
6.0.0
Development

Successfully merging a pull request may close this issue.

Get modules information using proc_pidinfo() on macOS k15tfu/runtime
5 participants
@k15tfu @jeffschwMSFT @mikem8361 @janvorli @Dotnet-GitSync-Bot