') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); })(); Fix macOS floating point corruption by janvorli · Pull Request #75440 · dotnet/runtime · GitHub
Skip to content

Fix macOS floating point corruption - #75440

Merged
janvorli merged 1 commit into
dotnet:mainfrom
janvorli:fix-macos-floating-point-corruption
Sep 12, 2022
Merged

Fix macOS floating point corruption#75440
janvorli merged 1 commit into
dotnet:mainfrom
janvorli:fix-macos-floating-point-corruption

Conversation

@janvorli

@janvorlijanvorli commented Sep 12, 2022

Copy link
Copy Markdown
Member

There is a race condition between activation signal handling and returning from a hardware exception handler on macOS. It shows up intermittently in the Regression/coreclr/GitHub_16833 test in the CI and I am able to repro it on my local mac once in several thousands of iterations of the test when running with GC stress C.

It turned out the issue is caused by the order in which we set parts of the context in the thread when returning from the hardware exception handler. MacOS can only set the floating point and control / integer portions separately. We were setting the control / integer portion first and the floating point portion after that. In the race condition, the signal handling code in the macOS extracts the context that contains the new control registers, but the old floating point ones (which is the state of those in the PAL_DispatchException). The signal handler for the activation injection then gets executed and when it returns later to our managed code, the floating point registers get restored to the wrong values.
I have figured this out by adding some instrumentation to the PAL / runtime, logging state of the PC and D0 registers to the stresslog in activation handler / hardware exception handler. I could see that the hardware exception handler was getting correct D0 at a PC and right away the activation handler was getting a corrupted D0at the same PC and the D0 matched what the formatted string contained in the failing test instead of the correct value (0xcccccccccccccccc or rarely 0).

The fix is to change the context setting to first set the floating point registers and then the control / integer portion of the context.

With the fix, the test was running over the whole weekend without any crashes.

Close#66568

@janvorli
Fix macOS floating point corruption
b92bf94
There is a race condition between activation signal handling and returning
from a hardware exception handler on macOS. It shows up intermittently in
the Regression/coreclr/GitHub_16833 test in the CI and I am able to repro
it on my local mac once in several thousands of iterations of the test when
running with GC stress C.
It turned out the issue is caused by the order in which we set parts of the
context in the thread when returning from the hardware exception handler.
MacOS can only set the floating point and control / integer portions separately.
We were setting the control / integer portion first and the floating point
portion after that. In the race condition, the signal handling code in the
macOS extracts the context that contains the new control registers, but the
old floating point ones (which is the state of those in the PAL_DispatchException).
The signal handler for the activation injection then gets executed and when it
returns later to our managed code, the floating point registers get restored
to the wrong values.
The fix is to change the context setting to first set the floating point
registers and then the control / integer portion of the context.
Closedotnet#66568
@janvorlijanvorli added the area-PAL-coreclr only for closed issues label Sep 12, 2022
@janvorlijanvorli added this to the 7.0.0 milestone Sep 12, 2022
@janvorlijanvorli self-assigned this Sep 12, 2022
@janvorli

janvorli commented Sep 12, 2022

Copy link
Copy Markdown
MemberAuthor

cc: @mangod9

@janvorli

janvorli commented Sep 12, 2022

Copy link
Copy Markdown
MemberAuthor

cc: @AntonLapounov

@AntonLapounov

AntonLapounov commented Sep 12, 2022

Copy link
Copy Markdown
Contributor

In the race condition, the signal handling code in the macOS extracts the context that contains the new control registers, but the old floating point ones

The fix is to change the context setting to first set the floating point registers and then the control / integer portion of the context.

What prevents the opposite case, i.e. using the old control registers with the new floating point ones? Thanks for catching this!

jkotas
jkotas reviewed Sep 12, 2022
View reviewed changes
Comment threadsrc/coreclr/pal/src/thread/context.cpp
}
}

if (lpContext->ContextFlags & (CONTEXT_CONTROL|CONTEXT_INTEGER) & CONTEXT_AREA_MASK)

@jkotasjkotasSep 12, 2022

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be useful to add a note that the integer/control registers have to be set last.

jkotas
jkotas approved these changes Sep 12, 2022
View reviewed changes

@jkotasjkotas left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@janvorli
janvorli merged commit 96f5037 into dotnet:mainSep 12, 2022
@janvorli

janvorli commented Sep 12, 2022

Copy link
Copy Markdown
MemberAuthor

/backport to release/7.0

@github-actions

github-actionsBot commented Sep 12, 2022

Copy link
Copy Markdown
Contributor

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3039605422

@github-actionsgithub-actionsBot mentioned this pull request Sep 12, 2022
Merged
@tannergoodingtannergooding mentioned this pull request Sep 13, 2022
Closed
4 tasks
@ghostghost locked as resolved and limited conversation to collaborators Oct 12, 2022
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@jkotasjkotasjkotas approved these changes
@VSadovVSadovAwaiting requested review from VSadov

Assignees

@janvorlijanvorli

Labels

area-PAL-coreclronly for closed issues

Projects

None yet

Milestone

7.0.0

Development

Successfully merging this pull request may close these issues.

Test failure Regressions/coreclr/GitHub_16833/Test16833/Test16833.sh

3 participants

@janvorli@AntonLapounov@jkotas