[PATCH] test: Fix and stabilize tst-wcsmbs-clone-overflow test

Adhemerval Zanella Netto adhemerval.zanella@linaro.org
Tue May 26 16:36:14 GMT 2026



On 26/05/26 13:20, Frederic Berat wrote:
> 
> 
> On Tue, May 26, 2026 at 2:54 PM Adhemerval Zanella Netto <adhemerval.zanella@linaro.org <mailto:adhemerval.zanella@linaro.org>> wrote:
> 
> 
> 
>     On 26/05/26 08:45, Frédéric Bérat wrote:
>     > The test tst-wcsmbs-clone-overflow was initially added to tests-static.
>     > However, this causes the test to be unstable because gconv modules
>     > dynamically load libc.so. Any discrepancy between the statically linked
>     > version and the dynamically loaded one can lead to a crash.
> 
>     It is not clear when this would happen, is it the case that the tests
>     is loading the system gconv modules instead of the one in the build
>     directory?
> 
> 
> If my understanding of the strace is correct, gconv dlopen the system's libc during its execution, leading to potential mismatch between the statically linked libc and the dlopen'ed one.
> That's also the only explanation I could find for the SIGFPE raised on linaro boxes on arm: GDB traces show the SIGFPE being raised during the dlopen operation.
> Note that while I could reproduce the SIGFPE until Tuesday last week, I couldn't on Wednesday. I therefore assumed that the Linaro image got updated with a Glibc version close enough to the one I tested that it no longer triggered the SIGFPE.
That is unexpected, the GCONV_PATH should handle this case to avoid messing
with system libraries (including gconv modules). I have stumbled on some
tests that need to handling to work without --enable-hardcoded-path-in-tests,
so maybe this is case.

In any case, I would consider a test issue if it relies and/or uses system
configuration.  For the hard cases we have the test-container to avoid
such issues.


More information about the Libc-alpha mailing list