[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