Repository navigation
Crash of mono interpreter tests with SIGSEV when running ODBC tests #116482
Description
Build Information
Build: https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_build/results?buildId=1063262
Build error leg or test failing: Work Item System.Data.Odbc.Tests
Pull request: #116459
Error Message
Fill the error message using step by step known issues guidance.
{
"ErrorMessage": ["MONO_ENV_OPTIONS=--interpreter", "Got a SIGSEGV while executing native code."],
"ErrorPattern": "",
"BuildRetry": false,
"ExcludeConsoleLog": false
}Could be related to #114123
Two test logs, both System.Data.Odbc from the same commit:
Seems too consistent to be a coincidence.
Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1063262
Error message validated: [MONO_ENV_OPTIONS=--interpreter Got a SIGSEGV while executing native code.]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 6/10/2025 3:27:56 PM UTC
Report
Summary
| 24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
|---|---|---|
| 0 | 2 | 16 |
Activity
lewing commentedon Jun 10, 2025
@BrzVlad I don't recall seeing this crash before, can you take a look?
dotnet-policy-service commentedon Jun 10, 2025
Tagging subscribers to this area: @BrzVlad, @kotlarmilos
See info in area-owners.md if you want to be subscribed.
BrzVlad commentedon Jun 11, 2025
This is same issue as #101370. This is fixed on main, but didn't seem particularly important for a backport. 9.0.5 also manifests this crash.
ericstj commentedon Jun 11, 2025
Not sure how common a customer application is to hit this, but typically crashing bugs like this meet the bar for servicing. I raised this because we didn't have a known issue tracking it and we need to be able to sort through the noise in servicing - these test runs are a big portion of what gives us a quality read in servicing where we have less folks using the builds before release.
BrzVlad commentedon Jun 11, 2025
This issue would be reproducible if you have a PInvoke that fails to resolve. So, in practice, this is probably not a likely scenario since I guess it means you already have an issue with your application. I wouldn't consider it high priority, but we could backport it as well, the fix is low risk.
vitek-karas commentedon Jun 30, 2025
@BrzVlad could you please decide if we will backport this? If not, please close this.
BrzVlad commentedon Jul 2, 2025
In my opinion it is not worth to backport the fix. I would still keep this issue open while net9 is active so it is referenced for failing builds. Alternatively I guess we could disable this test suite on interpreter, on net9 branch if you think this is a better approach.
vitek-karas commentedon Jul 2, 2025
I'd be fine disabling the test - either a single test case if it can be focused, or even the whole suite if necessary. There's no value in running it as it will fail all the time.
vitek-karas commentedon Jul 16, 2025
@BrzVlad Should we resolve this - it's fixed in 10 and we're not planning to fix it in 9.