GNU bug report logs - #70104
"FAIL: test-canonicalize" coreutils v9.5 on musl libc

Previous Next

To reply to this bug, email your comments to 70104 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Adept's Lab" <adeptslab <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: "FAIL: test-canonicalize" coreutils v9.5 on musl libc
Date: Sun, 31 Mar 2024 15:02:32 +0600

[Message part 1 (text/plain, inline)]

test-canonicalize.c:411: assertion 'strcmp (result1, "//") == 0' failed

^ the only error log message I get. Fail was not presented with previous
stable versions.

[Message part 2 (text/html, inline)]

Message #8 received at 70104 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Adept's Lab <adeptslab <at> gmail.com>, 70104 <at> debbugs.gnu.org
Cc: bug-gnulib <bug-gnulib <at> gnu.org>
Subject: Re: bug#70104: "FAIL: test-canonicalize" coreutils v9.5 on musl libc
Date: Sun, 31 Mar 2024 12:22:42 +0100

On 31/03/2024 10:02, Adept's Lab wrote:
> test-canonicalize.c:411: assertion 'strcmp (result1, "//") == 0' failed
> 
> ^ the only error log message I get. Fail was not presented with previous
> stable versions.

This is on musl 1.1.24 as detailed at:
https://github.com/coreutils/coreutils/issues/83

CC'ing bug-gnulib

cheers,
Pádraig

Message #11 received at 70104 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>,
 Adept's Lab <adeptslab <at> gmail.com>, 70104 <at> debbugs.gnu.org
Cc: bug-gnulib <bug-gnulib <at> gnu.org>
Subject: Re: bug#70104: "FAIL: test-canonicalize" coreutils v9.5 on musl libc
Date: Sun, 31 Mar 2024 07:56:55 -0600

On 3/31/24 05:22, Pádraig Brady wrote:
> On 31/03/2024 10:02, Adept's Lab wrote:
>> test-canonicalize.c:411: assertion 'strcmp (result1, "//") == 0' failed
>>
>> ^ the only error log message I get. Fail was not presented with previous
>> stable versions.
> 
> This is on musl 1.1.24 as detailed at:
> https://github.com/coreutils/coreutils/issues/83T
Does this behavior (of whether / and // are the same directory) depend 
on musl version, or on how musl is configured?

Message #14 received at 70104 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Pádraig Brady <P <at> draigbrady.com>,
 Adept's Lab <adeptslab <at> gmail.com>, 70104 <at> debbugs.gnu.org, bug-gnulib <at> gnu.org,
 Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#70104: "FAIL: test-canonicalize" coreutils v9.5 on musl libc
Date: Sun, 31 Mar 2024 21:45:08 +0200

[Message part 1 (text/plain, inline)]

Adept's Lab wrote:
> >> test-canonicalize.c:411: assertion 'strcmp (result1, "//") == 0' failed

Thanks for the report. I reproduce it with gnulib testdirs
  $ rm -rf ../testdir1; ./gnulib-tool --create-testdir --dir=../testdir1 --single-configure canonicalize-lgpl
  $ rm -rf ../testdir2; ./gnulib-tool --create-testdir --dir=../testdir2 --single-configure canonicalize
when run on Alpine Linux 3.9, 3.14, and 3.19.

History of these failures:
  - For many years, one of the tests was failing on Alpine Linux.
  - On 2021-01-17, I added a fix, that consists of a realpath() override [1].
  - On 2022-07-31, the bug was reported again [2], against the sed-4.8 release
    which predates the 2021-01-17 fix [3].
  - On 2023-09-04, Paul changed the behaviour of the unit tests on musl libc,
    without giving an explanation [4].
  - Now, the unit tests fail again, as reported above.

I'm therefore partially reverting Paul's change from 2023-09-04 (attached).

Paul Eggert wrote:
> Does this behavior (of whether / and // are the same directory) depend 
> on musl version, or on how musl is configured?

I think you must ask this to yourself:
  - What caused you to change the unit tests on 2023-09-04?
  - How is the musl version that you used on that date configured?
    What I use is Alpine Linux, as I said in versions 3.9, 3.14, 3.19.
  - Did you work with gnulib testdirs at that time, or did you use
    a package in which some modules are --avoid ed from import?

Bruno

[1] https://lists.gnu.org/archive/html/bug-gnulib/2021-01/msg00215.html
[2] https://lists.gnu.org/archive/html/bug-sed/2022-07/msg00003.html
[3] https://ftp.gnu.org/gnu/sed/
[4] https://lists.gnu.org/archive/html/bug-gnulib/2023-09/msg00011.html

[0001-canonicalize-lgpl-tests-Fix-test-failure-on-musl-lib.patch (text/x-patch, attachment)]

Message #17 received at 70104 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bruno Haible <bruno <at> clisp.org>, Pádraig Brady
 <P <at> draigbrady.com>, Adept's Lab <adeptslab <at> gmail.com>,
 70104 <at> debbugs.gnu.org, bug-gnulib <at> gnu.org
Subject: Re: bug#70104: "FAIL: test-canonicalize" coreutils v9.5 on musl libc
Date: Sun, 31 Mar 2024 21:35:29 -0700

On 2024-03-31 12:45, Bruno Haible wrote:
> I think you must ask this to yourself:
>    - What caused you to change the unit tests on 2023-09-04?
>    - How is the musl version that you used on that date configured?
>      What I use is Alpine Linux, as I said in versions 3.9, 3.14, 3.19.
>    - Did you work with gnulib testdirs at that time, or did you use
>      a package in which some modules are --avoid ed from import?

Thanks for fixing the problem. I cannot now remember why I put that musl 
stuff in. I suspect that I got it from some tests in some other package, 
but don't recall which ones. I don't use musl myself.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.