[Bug testsuite/34055] New: utf_user.exp / utf_kernel.exp tests sometimes fail on rawhide

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=34055

            Bug ID: 34055
           Summary: utf_user.exp / utf_kernel.exp tests sometimes fail on
                    rawhide
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: testsuite
          Assignee: systemtap at sourceware dot org
          Reporter: fche at redhat dot com
  Target Milestone: ---

https://builder.sourceware.org/testrun/140a39a88382cccc14ffc36f1c9a07c185a048a4?focus=dejagnu&search=utf_

indicates a number of FAIL's.  Let's nuke those.  One AI suspects:

The test is failing because the raw output produced by SystemTap is no longer
matching the `expect` string patterns set in the testing framework. Here is
what is happening:

### `utf_user.exp` and `utf_kernel.exp`
```text
FAIL: utf_user
line 2: expected "stap\x7f\x80Got
"stap\x7fÂ\x80Î\x91Ω߿à\xa0\x80â\x98ºï¿¿ð\x90\x80\x80ð\x9f\x98\x88ô\x8f¿¿"
   
""stap\177\u0080\u0391\u03A9\u07FF\u0800\u263A\uFFFF\U00010000\U0001F608\U0010FFFF""
```
Notice the mismatch here: The `expect` test is looking for raw byte `\x80`
right after `stap\x7f`. However, the actual text captured by the test framework
contains `Â\x80`. 

`Â\x80` (C2 80) is the proper UTF-8 encoded sequence for the Unicode code point
`U+0080`. The framework was seemingly trying to do a raw binary byte match
(`\x80`) but instead received and parsed properly encoded UTF-8 characters. 

### `utf_kernel_trunc.exp`
```text
FAIL: utf_kernel_trunc
line 3: expected "utf-16:01234567890123456789012345678901234567"
        Got "utf-16:01234567890123456789012345678901234567Ω"
```
Here, SystemTap's truncation limit (`-DMAXSTRINGLEN=41`) was triggered, but the
test framework is seeing the trailing string slice capture an extra `Ω` (Omega
character / `U+03A9`) that wasn't previously matching the truncation
expectation.

### The Real Culprit
Since this exact same SystemTap codebase passes cleanly on Fedora 42 and below,
this is overwhelmingly likely to be a change in the **Tcl/Expect** package
versions—or the system's default locale/encoding behavior—in the Fedora Rawhide
environment.

In Rawhide, `expect` appears to have switched to strictly parsing incoming
streams as UTF-8 rather than as raw ISO-8859-1 or binary bytes. This breaks the
Dejagnu test scripts that rely on hardcoded raw byte pattern matching (a very
common issue when scripting languages migrate to stricter default UTF-8
processing).

-- 
You are receiving this mail because:
You are the assignee for the bug.