** 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. * 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. * 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). [ 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. * 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. [ 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: - `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 (LP: #XXXXX). Noble is + 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
