Repository navigation
Disable computation of topStack on Windows platforms #54986
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -952,11 +952,32 @@ inline GC_ALLOC_FLAGS& operator&=(GC_ALLOC_FLAGS& a, GC_ALLOC_FLAGS b) | |
| #define UNCHECKED_OBJECTREF_TO_OBJECTREF(obj) (obj) | ||
| #endif | ||
|
|
||
| #if !defined(FEATURE_HIJACK) || defined(TARGET_UNIX) | ||
| #define FEATURE_SUPPORTS_STACK_LIMIT | ||
| #else | ||
| #if defined(FEATURE_CONSERVATIVE_GC) | ||
| // On Windows platforms when we hijack, we use SuspendThread from outside the thread, and if we suspend | ||
| // within an interruptible region, we can stop with the top Frame that is an InlinedCallFrame | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would expect
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You have a point. I thought I had managed to reproduce the scenario (or something very like it) in the debugger, but I agree, I can't quite see how we didn't end up with a proper RedirectedThreadFrame. In any case, the best crash dump I could get from the CI system had a disabled InlinedCallFrame as the top of the framestack. (Unfortunately, for some reason, the thread that frame is on had been terminated, so it wasn't completely workable.) I'll try a again with some debugger fun times. |
||
| // that is not active. In that situation, it is possible for the actual top of the stack to be a managed | ||
| // function which has a lower SP pointer than is reported from the InlinedCallFrame, or in the case of | ||
| // Windows x86 platforms, the InlinedCallFrame may report a GetCallSiteSP of 0, or of an value associated | ||
| // with some other callsite within the managed function that set up the InlinedCallFrame. This issue could | ||
| // be fixed by capturing the SP after suspension, and storing it on the thread object for use when setting | ||
| // stack_limit, but as conservative GC is not needed on any current Windows platforms, and the Unix scenario | ||
| // is fully functional, I've added this #error instead. | ||
| #error Conservative GC is not supported on this platform as the current computation of stack_limit is not strictly correct | ||
| #endif // FEATURE_CONSERVATIVE_GC | ||
| #endif // !defined(FEATURE_HIJACK) || defined(TARGET_UNIX) | ||
|
|
||
| struct ScanContext | ||
| { | ||
| Thread* thread_under_crawl; | ||
| int thread_number; | ||
| #ifdef FEATURE_SUPPORTS_STACK_LIMIT | ||
| uintptr_t stack_limit; // Lowest point on the thread stack that the scanning logic is permitted to read | ||
| #else | ||
| uintptr_t stack_limitUNUSED; // Keep the shape of ScanContext the same whether or not STACK_LIMIT is supported for use | ||
| #endif // FEATURE_SUPPORTS_STACK_LIMIT | ||
|
Comment on lines
+976
to
+980
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. do we really need this distinction in this file? GC doesn't care at all about whether this is a stack limit you maintain or not... it would be good to not have this knowledge in the GC interface unless it's mandatory... |
||
| bool promotion; //TRUE: Promotion, FALSE: Relocation. | ||
| bool concurrent; //TRUE: concurrent scanning | ||
| void* _unused1; | ||
|
|
@@ -973,7 +994,11 @@ struct ScanContext | |
|
|
||
| thread_under_crawl = 0; | ||
| thread_number = -1; | ||
| #ifdef FEATURE_SUPPORTS_STACK_LIMIT | ||
| stack_limit = 0; | ||
| #else | ||
| stack_limitUNUSED = 0; | ||
| #endif // FEATURE_SUPPORTS_STACK_LIMIT | ||
| promotion = false; | ||
| concurrent = false; | ||
| pMD = NULL; | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
functionally I don't see a problem. I'm curious - could interior be actually >= heap_segment_allocated if GCConfig::GetConservativeGC() is false? this would mean it's reporting an interior pointer that's indeed on a segment but not pointing at a valid object on that seg.