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

[embedding] Chaining Mach exceptions to Mono signals using utility threads #18011

Closed
lambdageek opened this issue Dec 3, 2019 · 1 comment
Closed

[embedding] Chaining Mach exceptions to Mono signals using utility threads #18011

lambdageek opened this issue Dec 3, 2019 · 1 comment
Assignees
@lambdageek
Labels
area-Runtime: Embedding area-Runtime: Threading os-macOS regression
Milestone
2019-10 (6.8.xx)

Comments

@lambdageek
Copy link
Member

See the README of https://github.com/lambdageek/mono-mach-exceptions

By default, Mono uses signals to handle NullReferenceException. Applications that want to use Mach exceptions to generate crash reports interfere with this, because Mach exceptions take priority over signals.

So the way the repo proposed to solve the issue was by creating a Mono tools thread that would listen on the Mach exception port and then dispatch the exception to the old listener (Which would raise a SEGV in Mono which would then try to raise a managed NRE if the thread was running some managed function).

In a5da7b2 we got rid of tools threads in favor of normal attach and using mono_thread_info_set_flags to exclude the thread from GC pauses and profiler signals.

Not sure what the best approach is yet:

  1. Bring back mono_threads_attach_tools_thread and just have it set the thread info flags.
  2. Find some other way to cooperate with Mach exceptions better.
@lambdageek lambdageek self-assigned this Dec 3, 2019
@lambdageek lambdageek added this to the 2019-10 (6.8.xx) milestone Dec 3, 2019
lambdageek added a commit to lambdageek/mono that referenced this issue Dec 4, 2019
@lambdageek
[utils] Add back mono_threads_attach_tools_thread
b9674ff 
In mono@a5da7b2
we got rid of "tools" threads internally to the runtime.

However since the API was previously marked with MONO_API it was an internal
API that some embedders depended on.

This PR adds back an (external-only) limited form of tools thread.

The runtime is aware of the Tools thread in that FOREACH_THREAD_* macros will
iterate over them, and the thread has a coop thread state machine. (That is,
mono_thread_info_current() and GC Safe and GC Unsafe transitions all work.)

However the thread is:
1. Not stopped by the GC
2. Is not interrupted by profiler sampling.
3. Does not have a "current domain"
4. (As a consequence of the above) cannot call managed methods or touch managed
objects.

Such threads are useful for low-level interaction with the runtime such as
querying metadata, the JIT state and other coordination.

mono_threads_attach_tools_thread should be called no more than once.  It should
not be called on a thread that is already attached with mono_thread_atach, and
vice versa.

Addresses mono#18011
@lambdageek lambdageek mentioned this issue Dec 4, 2019
Merged
monojenkins pushed a commit to monojenkins/mono that referenced this issue Dec 6, 2019
@lambdageek @monojenkins
[utils] Add back mono_threads_attach_tools_thread
77e0a0c 
In mono@a5da7b2
we got rid of "tools" threads internally to the runtime.

However since the API was previously marked with MONO_API it was an internal
API that some embedders depended on.

This PR adds back an (external-only) limited form of tools thread.

The runtime is aware of the Tools thread in that FOREACH_THREAD_* macros will
iterate over them, and the thread has a coop thread state machine. (That is,
mono_thread_info_current() and GC Safe and GC Unsafe transitions all work.)

However the thread is:
1. Not stopped by the GC
2. Is not interrupted by profiler sampling.
3. Does not have a "current domain"
4. (As a consequence of the above) cannot call managed methods or touch managed
objects.

Such threads are useful for low-level interaction with the runtime such as
querying metadata, the JIT state and other coordination.

mono_threads_attach_tools_thread should be called no more than once.  It should
not be called on a thread that is already attached with mono_thread_atach, and
vice versa.

Addresses mono#18011
monojenkins pushed a commit to monojenkins/mono that referenced this issue Dec 6, 2019
@lambdageek @monojenkins
[utils] Add back mono_threads_attach_tools_thread
350e6ae 
In mono@a5da7b2
we got rid of "tools" threads internally to the runtime.

However since the API was previously marked with MONO_API it was an internal
API that some embedders depended on.

This PR adds back an (external-only) limited form of tools thread.

The runtime is aware of the Tools thread in that FOREACH_THREAD_* macros will
iterate over them, and the thread has a coop thread state machine. (That is,
mono_thread_info_current() and GC Safe and GC Unsafe transitions all work.)

However the thread is:
1. Not stopped by the GC
2. Is not interrupted by profiler sampling.
3. Does not have a "current domain"
4. (As a consequence of the above) cannot call managed methods or touch managed
objects.

Such threads are useful for low-level interaction with the runtime such as
querying metadata, the JIT state and other coordination.

mono_threads_attach_tools_thread should be called no more than once.  It should
not be called on a thread that is already attached with mono_thread_atach, and
vice versa.

Addresses mono#18011
This was referenced Dec 6, 2019
Merged
Merged
lambdageek added a commit that referenced this issue Dec 6, 2019
@lambdageek
[threads] Add back mono_threads_attach_tools_thread as a public API (#…
3dabedd 
…18048)

* [utils] Add back mono_threads_attach_tools_thread

In a5da7b2
we got rid of "tools" threads internally to the runtime.

However since the API was previously marked with MONO_API it was an internal
API that some embedders depended on.

This PR adds back an (external-only) limited form of tools thread.

The runtime is aware of the Tools thread in that FOREACH_THREAD_* macros will
iterate over them, and the thread has a coop thread state machine. (That is,
mono_thread_info_current() and GC Safe and GC Unsafe transitions all work.)

However the thread is:
1. Not stopped by the GC
2. Is not interrupted by profiler sampling.
3. Does not have a "current domain"
4. (As a consequence of the above) cannot call managed methods or touch managed
objects.

Such threads are useful for low-level interaction with the runtime such as
querying metadata, the JIT state and other coordination.

mono_threads_attach_tools_thread should be called no more than once.  It should
not be called on a thread that is already attached with mono_thread_atach, and
vice versa.

Addresses #18011

* [threads] Make mono_threads_attach_tools_thread into a public API
lambdageek pushed a commit that referenced this issue Dec 6, 2019
@monojenkins @lambdageek
[2019-10] [threads] Add back mono_threads_attach_tools_thread as a pu…
6ac1197 
…blic API (#18075)

* [utils] Add back mono_threads_attach_tools_thread

In a5da7b2
we got rid of "tools" threads internally to the runtime.

However since the API was previously marked with MONO_API it was an internal
API that some embedders depended on.

This PR adds back an (external-only) limited form of tools thread.

The runtime is aware of the Tools thread in that FOREACH_THREAD_* macros will
iterate over them, and the thread has a coop thread state machine. (That is,
mono_thread_info_current() and GC Safe and GC Unsafe transitions all work.)

However the thread is:
1. Not stopped by the GC
2. Is not interrupted by profiler sampling.
3. Does not have a "current domain"
4. (As a consequence of the above) cannot call managed methods or touch managed
objects.

Such threads are useful for low-level interaction with the runtime such as
querying metadata, the JIT state and other coordination.

mono_threads_attach_tools_thread should be called no more than once.  It should
not be called on a thread that is already attached with mono_thread_atach, and
vice versa.

Addresses #18011

* [threads] Make mono_threads_attach_tools_thread into a public API
akoeplinger pushed a commit that referenced this issue Dec 9, 2019
@monojenkins @akoeplinger
[2019-12] [threads] Add back mono_threads_attach_tools_thread as a pu…
cbc3a80 
…blic API (#18074)

* [utils] Add back mono_threads_attach_tools_thread

In a5da7b2
we got rid of "tools" threads internally to the runtime.

However since the API was previously marked with MONO_API it was an internal
API that some embedders depended on.

This PR adds back an (external-only) limited form of tools thread.

The runtime is aware of the Tools thread in that FOREACH_THREAD_* macros will
iterate over them, and the thread has a coop thread state machine. (That is,
mono_thread_info_current() and GC Safe and GC Unsafe transitions all work.)

However the thread is:
1. Not stopped by the GC
2. Is not interrupted by profiler sampling.
3. Does not have a "current domain"
4. (As a consequence of the above) cannot call managed methods or touch managed
objects.

Such threads are useful for low-level interaction with the runtime such as
querying metadata, the JIT state and other coordination.

mono_threads_attach_tools_thread should be called no more than once.  It should
not be called on a thread that is already attached with mono_thread_atach, and
vice versa.

Addresses #18011

* [threads] Make mono_threads_attach_tools_thread into a public API
@lambdageek
Copy link
Member Author

This is now fixed on 2019-10 (#18075), 2019-12 (#18074) and master (#18048).

ManickaP pushed a commit to ManickaP/runtime that referenced this issue Jan 20, 2020
@lambdageek
[threads] Add back mono_threads_attach_tools_thread as a public API (m…
45a050f 
…ono/mono#18048)

* [utils] Add back mono_threads_attach_tools_thread

In https://github.com/mono/mono/commit/mono/mono@a5da7b21f4b6dbc5eaa09c2addee91b84dc1dbd5
we got rid of "tools" threads internally to the runtime.

However since the API was previously marked with MONO_API it was an internal
API that some embedders depended on.

This PR adds back an (external-only) limited form of tools thread.

The runtime is aware of the Tools thread in that FOREACH_THREAD_* macros will
iterate over them, and the thread has a coop thread state machine. (That is,
mono_thread_info_current() and GC Safe and GC Unsafe transitions all work.)

However the thread is:
1. Not stopped by the GC
2. Is not interrupted by profiler sampling.
3. Does not have a "current domain"
4. (As a consequence of the above) cannot call managed methods or touch managed
objects.

Such threads are useful for low-level interaction with the runtime such as
querying metadata, the JIT state and other coordination.

mono_threads_attach_tools_thread should be called no more than once.  It should
not be called on a thread that is already attached with mono_thread_atach, and
vice versa.

Addresses mono/mono#18011

* [threads] Make mono_threads_attach_tools_thread into a public API


Commit migrated from mono/mono@3dabedd
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lambdageek lambdageek

Labels
area-Runtime: Embedding area-Runtime: Threading os-macOS regression
Projects
None yet
Milestone
2019-10 (6.8.xx)
Development

No branches or pull requests
1 participant
@lambdageek