** Description changed: [ Impact ] - * dotnet10 autopkgtests `debugging-sos-lldb-via-core` and - `debugging-via-dotnet-dump` started failing on amd64, amd64v3 and arm64. The - failure first appeared in stonking (devel) proposed and now also affects - resolute, where dotnet10 10.0.112 is already published in - resolute-security/resolute-updates. ppc64el and s390x are not affected: - those two tests are skipped there because the Turkey test runner reports - `runtime=mono` on those architectures. + * dotnet10 autopkgtests `debugging-sos-lldb-via-core` and + `debugging-via-dotnet-dump` started failing on amd64, amd64v3 and arm64. The + failure first appeared in stonking (devel) proposed and now also affects + resolute, where dotnet10 10.0.112 is already published in + resolute-security/resolute-updates. ppc64el and s390x are not affected: + those two tests are skipped there because the Turkey test runner reports + `runtime=mono` on those architectures. - * The failing assertion is `grep 'EEClass: '` on the output of the `name2ee` - command. The tests install the latest `dotnet-sos` and `dotnet-dump` global - tools from NuGet at run time; version 10.0.745401 (published 2026-09-03..07) - included a C# rewrite of `name2ee` - (https://github.com/dotnet/diagnostics/issues/5719) which no longer emits - the `EEClass:` field and only reports the module where a method is defined, - not every referencing assembly. The test scripts still grepped for - `EEClass:` (and for module names) and abort under `set -e`. + * The failing assertion is `grep 'EEClass: '` on the output of the `name2ee` + command. The tests install the latest `dotnet-sos` and `dotnet-dump` global + tools from NuGet at run time; version 10.0.745401 (published 2026-09-03..07) + included a C# rewrite of `name2ee` + (https://github.com/dotnet/diagnostics/issues/5719) which no longer emits + the `EEClass:` field and only reports the module where a method is defined, + not every referencing assembly. The test scripts still grepped for + `EEClass:` (and for module names) and abort under `set -e`. - * There is no user-facing impact: this is strictly an autopkgtest regression. - However, failing autopkgtests blocked the dotnet10 migration on stonking - and now fail the test verification for the resolute updates pocket, so the - archive can no longer verify the package. Keeping these tests green is the - justification for backporting this test-only change to resolute. + * There is no user-facing impact: this is strictly an autopkgtest regression. + However, failing autopkgtests blocked the dotnet10 migration on stonking + and now fail the test verification for the resolute updates pocket, so the + archive can no longer verify the package. Keeping these tests green is the + justification for backporting this test-only change to resolute. - * The upload fixes the bug by updating `debian/tests/regular-tests` to the - new `name2ee` output format: the stale `EEClass:`/module greps are removed - (upstream #432), and the `dumpclass` command is reworked to use the - `dumpmt` output, taking the `EEClass` address from it when present (.NET 8) - or falling back to passing the MethodTable directly (.NET 9+), as - `dumpclass` now accepts (upstream #433). + * The upload fixes the bug by updating `debian/tests/regular-tests` (updating the following repo: https://github.com/canonical/dotnet-regular-tests) to the + new `name2ee` output format: the stale `EEClass:`/module greps are removed + (upstream #432), and the `dumpclass` command is reworked to use the + `dumpmt` output, taking the `EEClass` address from it when present (.NET 8) + or falling back to passing the MethodTable directly (.NET 9+), as + `dumpclass` now accepts (https://github.com/redhat-developer/dotnet-regular-tests/pull/433). [ Test Plan ] - * Reproduce the failure (current resolute/proposed binaries, old tests): run - the `run-regular-tests` autopkgtest for dotnet10, e.g. - ``` - autopkgtest --apt-pocket=proposed=src:dotnet10 \ - --env=ADT_TEST_TRIGGERS=dotnet10/10.0.112-10.0.12-0ubuntu1 \ - dotnet10 -- lxd autopkgtest/ubuntu/stonking/amd64 - ``` - The tests `debugging-sos-lldb-via-core` and `debugging-via-dotnet-dump` - fail on amd64/amd64v3/arm64 at `grep 'EEClass: '`. The same failure can - be reproduced locally by running the two test scripts directly against a - stonking testbed with dotnet-sdk-10.0 10.0.112 installed. + * Reproduce the failure (current resolute/proposed binaries, old tests): run + the `run-regular-tests` autopkgtest for dotnet10, e.g. + ``` + autopkgtest --apt-pocket=proposed=src:dotnet10 \ + --env=ADT_TEST_TRIGGERS=dotnet10/10.0.112-10.0.12-0ubuntu1 \ + dotnet10 -- lxd autopkgtest/ubuntu/stonking/amd64 + ``` + The tests `debugging-sos-lldb-via-core` and `debugging-via-dotnet-dump` + fail on amd64/amd64v3/arm64 at `grep 'EEClass: '`. The same failure can + be reproduced locally by running the two test scripts directly against a + stonking testbed with dotnet-sdk-10.0 10.0.112 installed. - * Verify the fix: run the same autopkgtest with the updated tests (the - stonking 10.0.112-10.0.12-0ubuntu2 source tree, or via `REGULAR_TESTS_REF` - pointing at canonical/dotnet-regular-tests commit dcbcea4). Both tests now - PASS, and the full 62-test `run-regular-tests` suite passes. This was - validated locally on an amd64 stonking (26.10) multipass VM: the two tests - failed before the change and pass after it. + * Verify the fix: run the same autopkgtest with the updated tests (the + stonking 10.0.112-10.0.12-0ubuntu2 source tree, or via `REGULAR_TESTS_REF` + pointing at canonical/dotnet-regular-tests commit dcbcea4). Both tests now + PASS, and the full 62-test `run-regular-tests` suite passes. This was + validated locally on an amd64 stonking (26.10) multipass VM: the two tests + failed before the change and pass after it. - * Before landing the SRU, the full `run-regular-tests` suite should pass on - amd64; arm64/amd64v3 will be covered by the archive's autopkgtest runs on - the proposed upload. + * The built packages for this SRU are currently building in the following + PPA: https://launchpad.net/~rinconjr/+archive/ubuntu/dotnet10-servicing-sep-2026-final-3/+packages + + * Before landing the SRU, the full `run-regular-tests` suite should pass on + amd64; arm64/amd64v3 will be covered by the archive's autopkgtest runs on + the proposed upload. [ Where problems could occur ] - * The change touches only `debian/tests/regular-tests` (test scripts); no - packaged binaries are modified, so a regression cannot affect runtime - behaviour. The risks are limited to the test suite itself: + * The change touches only `debian/tests/regular-tests` (test scripts); no + packaged binaries are modified, so a regression cannot affect runtime + behaviour. The risks are limited to the test suite itself: - - `dumpclass` now depends on `dumpmt` output. If a future `dotnet-sos` - release changes `dumpmt` (the way this release changed `name2ee`), the - `dumpclass` step could fail again. The fallback logic (EEClass from - `dumpmt`, else MethodTable) mitigates this for the known .NET 8 vs 9+ - differences, but a future diagnostics change could still break the - assertion and cause a test failure that would need a follow-up test - update. - - Removing the `EEClass:`/module-name greps reduces coverage slightly: the - tests no longer verify that `name2ee` reports `System.String`'s EEClass - or that `ToString` is resolved in TestDir.dll/System.Runtime.dll/ - Microsoft.AspNetCore.dll. A structural change in the runtime's debug info - that those greps used to catch would no longer be detected by these - tests. - - The `dumpclass`/`gcroot` steps contain existing aarch64-specific guards; - the changes keep those guards intact, but any arm64-only issue would only - be caught by the arm64 autopkgtest run. - - The tests install the *latest* `dotnet-sos`/`dotnet-dump` from NuGet on - every run, so the suite is inherently sensitive to upstream tool changes. - A regression here would appear as an autopkgtest failure, not as a - user-facing problem, and would be addressed by another test-suite sync. + - `dumpclass` now depends on `dumpmt` output. If a future `dotnet-sos` + release changes `dumpmt` (the way this release changed `name2ee`), the + `dumpclass` step could fail again. The fallback logic (EEClass from + `dumpmt`, else MethodTable) mitigates this for the known .NET 8 vs 9+ + differences, but a future diagnostics change could still break the + assertion and cause a test failure that would need a follow-up test + update. + - Removing the `EEClass:`/module-name greps reduces coverage slightly: the + tests no longer verify that `name2ee` reports `System.String`'s EEClass + or that `ToString` is resolved in TestDir.dll/System.Runtime.dll/ + Microsoft.AspNetCore.dll. A structural change in the runtime's debug info + that those greps used to catch would no longer be detected by these + tests. + - The `dumpclass`/`gcroot` steps contain existing aarch64-specific guards; + the changes keep those guards intact, but any arm64-only issue would only + be caught by the arm64 autopkgtest run. + - The tests install the *latest* `dotnet-sos`/`dotnet-dump` from NuGet on + every run, so the suite is inherently sensitive to upstream tool changes. + A regression here would appear as an autopkgtest failure, not as a + user-facing problem, and would be addressed by another test-suite sync. [ Other Info ] - * Root cause is upstream (dotnet/diagnostics#5719); the fix follows upstream - redhat-developer/dotnet-regular-tests PR #432 and #433 (authored by Tom - Deseyn), cherry-picked into canonical/dotnet-regular-tests at commit - dcbcea4e70f81a5d504da6f6788edc4407a39edb. - * The stonking (devel) fix is packaged as 10.0.112-10.0.12-0ubuntu2 and is - being uploaded to stonking directly (devel release, no SRU needed). This - bug tracks the same change for the resolute SRU, packaged as - 10.0.112-10.0.12-0ubuntu2~26.04.1 for resolute-security. Both changelog - entries (src/changelog.dotnet10.stonking and - src/changelog.dotnet10.resolute) reference this bug. Noble is - expected to receive the same fix in a subsequent update and can be added to - this bug when that SRU is prepared. - * The tests are synced into the package from canonical/dotnet-regular-tests - via flamenco (`src/tests/regular-tests/flamenco.json`), so this is a normal - test-suite sync rather than a bespoke packaging change. - * ppc64el/s390x do not exercise the changed code paths (tests skipped), so no - impact is expected there. - * Because the `migration-reference/0` run has already failed, dotnet10 no - longer blocks other packages from migrating; the SRU is pursued to keep the - package's tests green rather than to unblock migration. + * Root cause is upstream (dotnet/diagnostics#5719 - https://github.com/dotnet/diagnostics/pull/5719); the fix follows upstream + redhat-developer/dotnet-regular-tests PR #432 and #433 (authored by Tom + Deseyn), cherry-picked into canonical/dotnet-regular-tests at commit + dcbcea4e70f81a5d504da6f6788edc4407a39edb (https://github.com/canonical/dotnet-regular-tests/commit/dcbcea4e70f81a5d504da6f6788edc4407a39edb). + + * The stonking (devel) fix is packaged as 10.0.112-10.0.12-0ubuntu2 and is + being uploaded to stonking directly (devel release, no SRU needed). This + bug tracks the same change for the resolute SRU, packaged as + 10.0.112-10.0.12-0ubuntu2~26.04.1 for resolute-security. Both changelog + entries (src/changelog.dotnet10.stonking and + src/changelog.dotnet10.resolute) reference this bug. Noble is + expected to receive the same fix in a subsequent update and can be added to + this bug when that SRU is prepared. + + * The tests are synced into the package from canonical/dotnet-regular-tests + via flamenco (`src/tests/regular-tests/flamenco.json`), so this is a normal + test-suite sync rather than a bespoke packaging change. + + * ppc64el/s390x do not exercise the changed code paths (tests skipped), so no + impact is expected there. + + * Because the `migration-reference/0` run has already failed, dotnet10 no + longer blocks other packages from migrating; the SRU is pursued to keep the + package's tests green rather than to unblock migration.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2167382 Title: autopkgtest regression: debugging-sos-lldb-via-core and debugging-via- dotnet-dump fail To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dotnet10/+bug/2167382/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
