Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cwd_enoent.t fails on DragonFly BSD #16525

Closed
p5pRT opened this issue Apr 22, 2018 · 25 comments · Fixed by #19951
Closed

cwd_enoent.t fails on DragonFly BSD #16525

p5pRT opened this issue Apr 22, 2018 · 25 comments · Fixed by #19951
Assignees

Comments

@p5pRT
Copy link

p5pRT commented Apr 22, 2018

Migrated from rt.perl.org#133141 (status was 'open')

Searchable as RT133141$

@p5pRT
Copy link
Author

p5pRT commented Apr 22, 2018

From @xenu

On the latest blead​:


% ./perl -I ../lib ../dist/PathTools/t/cwd_enoent.t
1..8
not ok 1 - regular getcwd result on non-existent directory
# Failed test 'regular getcwd result on non-existent directory'
# at ../dist/PathTools/t/cwd_enoent.t line 34.
# got​: '/tmp/LPDQmQvz61/testdir'
# expected​: undef
not ok 2 - regular getcwd errno on non-existent directory
# Failed test 'regular getcwd errno on non-existent directory'
# at ../dist/PathTools/t/cwd_enoent.t line 35.
# got​: '0'
# expected​: '2'
not ok 3 - regular abs_path result on non-existent directory
# Failed test 'regular abs_path result on non-existent directory'
# at ../dist/PathTools/t/cwd_enoent.t line 39.
# got​: '/tmp/LPDQmQvz61/testdir'
# expected​: undef
not ok 4 - regular abs_path errno on non-existent directory
# Failed test 'regular abs_path errno on non-existent directory'
# at ../dist/PathTools/t/cwd_enoent.t line 40.
# got​: '0'
# expected​: '2'
ok 5 - perl getcwd result on non-existent directory
ok 6 - perl getcwd errno on non-existent directory
ok 7 - perl abs_path result on non-existent directory
ok 8 - perl abs_path errno on non-existent directory
# Looks like you failed 4 tests of 8.


The problem is similar to #132733, getcwd() doesn't fail on non-existent
directories on DragonFly BSD.

I'm sure it's a bug in DragonFly, but I think we should skip failing
tests until it's fixed upstream.

@p5pRT
Copy link
Author

p5pRT commented Apr 22, 2018

From @xenu

The patch is attached.

@p5pRT
Copy link
Author

p5pRT commented Apr 22, 2018

From @xenu

0001-getcwd-doesn-t-fail-on-non-existent-directories-on-D.patch
From 0db64c5b2058a7a3c33e2e9a58ff4bda04a30833 Mon Sep 17 00:00:00 2001
From: Tomasz Konojacki <me@xenu.pl>
Date: Sun, 22 Apr 2018 23:49:59 +0200
Subject: [PATCH 1/1] getcwd() doesn't fail on non-existent directories on
 DragonFly BSD.

Until it's fixed upstream, we should skip tests that don't expect
this behaviour.

[RT #133141]
---
 dist/PathTools/t/cwd_enoent.t | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/dist/PathTools/t/cwd_enoent.t b/dist/PathTools/t/cwd_enoent.t
index ee99423cbb..b9adddeab7 100644
--- a/dist/PathTools/t/cwd_enoent.t
+++ b/dist/PathTools/t/cwd_enoent.t
@@ -24,6 +24,10 @@ foreach my $type (qw(regular perl)) {
 	skip "_perl_abs_path() not expected to work", 4
 	    if $type eq "perl" &&
 		!(($Config{prefix} =~ m/\//) && $^O ne "cygwin");
+
+	skip "getcwd() doesn't fail on non-existent directories on this platform", 4
+	    if $type eq 'regular' && $^O eq 'dragonfly';
+
 	no warnings "redefine";
 	local *Cwd::abs_path = \&Cwd::_perl_abs_path if $type eq "perl";
 	local *Cwd::getcwd = \&Cwd::_perl_getcwd if $type eq "perl";
-- 
2.17.0

@p5pRT
Copy link
Author

p5pRT commented Apr 24, 2018

From @jkeenan

On Sun, 22 Apr 2018 22​:07​:52 GMT, me@​xenu.pl wrote​:

The patch is attached.

Available for smoke-testing in​:
smoke-me/jkeenan/xenu/133141-dragonfly

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Apr 24, 2018

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Apr 24, 2018

From @khwilliamson

On 04/24/2018 12​:37 PM, James E Keenan via RT wrote​:

On Sun, 22 Apr 2018 22​:07​:52 GMT, me@​xenu.pl wrote​:

The patch is attached.

Available for smoke-testing in​:
smoke-me/jkeenan/xenu/133141-dragonfly

I support adding skips to tests during the freeze which fix failing
smokes. The changes are isolated to the particular .t, and don't affect
the functioning of the actual interpreter.

But I'm thinking that skips for OS bugs, like this, should have be
written so that they don't apply to any future version of the OS, if we
have any hope at all that the vendor will eventually fix it. If the OS
gets fixed, the test will automatically happen again; if a new version
of the OS is released, and is still broken, we would have to update the
test, but could then prod the vendor that this is an issue.

@p5pRT
Copy link
Author

p5pRT commented Apr 27, 2018

From @jkeenan

On Tue, 24 Apr 2018 18​:37​:20 GMT, jkeenan wrote​:

On Sun, 22 Apr 2018 22​:07​:52 GMT, me@​xenu.pl wrote​:

The patch is attached.

Available for smoke-testing in​:
smoke-me/jkeenan/xenu/133141-dragonfly

Xenu​: It appears that you are the only person smoking on Dragonfly at the moment. Could you please test this branch on those rigs?

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Apr 28, 2018

From @xenu

On Fri, 27 Apr 2018 11​:38​:17 -0700
"James E Keenan via RT" <perlbug-followup@​perl.org> wrote​:

Xenu​: It appears that you are the only person smoking on Dragonfly at the moment. Could you please test this branch on those rigs?

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

---
via perlbug​: queue​: perl5 status​: open
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133141

Looks good​: http​://perl5.test-smoke.org/report/65465

@p5pRT
Copy link
Author

p5pRT commented Apr 30, 2018

From @iabyn

On Tue, Apr 24, 2018 at 02​:18​:15PM -0600, Karl Williamson wrote​:

On 04/24/2018 12​:37 PM, James E Keenan via RT wrote​:

On Sun, 22 Apr 2018 22​:07​:52 GMT, me@​xenu.pl wrote​:

The patch is attached.

Available for smoke-testing in​:
smoke-me/jkeenan/xenu/133141-dragonfly

I support adding skips to tests during the freeze which fix failing smokes.
The changes are isolated to the particular .t, and don't affect the
functioning of the actual interpreter.

But I'm thinking that skips for OS bugs, like this, should have be written
so that they don't apply to any future version of the OS, if we have any
hope at all that the vendor will eventually fix it. If the OS gets fixed,
the test will automatically happen again; if a new version of the OS is
released, and is still broken, we would have to update the test, but could
then prod the vendor that this is an issue.

While agree in principle, this late in code freeze, I'm happy for that
patch to applies as-is (i.e. skip those tests if $^O eq 'dragonfly',
regardless of version).

The skip condition can always be softened later.

--
"I used to be with it, but then they changed what ‘it’ was, and now what
I’m with isn’t it. And what’s ‘it’ seems weird and scary to me."
  -- Grandpa Simpson
(It will happen to you too.)

@p5pRT
Copy link
Author

p5pRT commented Apr 30, 2018

From @xsawyerx

On 04/30/2018 03​:27 PM, Dave Mitchell wrote​:

On Tue, Apr 24, 2018 at 02​:18​:15PM -0600, Karl Williamson wrote​:

On 04/24/2018 12​:37 PM, James E Keenan via RT wrote​:

On Sun, 22 Apr 2018 22​:07​:52 GMT, me@​xenu.pl wrote​:

The patch is attached.
Available for smoke-testing in​:
smoke-me/jkeenan/xenu/133141-dragonfly

I support adding skips to tests during the freeze which fix failing smokes.
The changes are isolated to the particular .t, and don't affect the
functioning of the actual interpreter.

But I'm thinking that skips for OS bugs, like this, should have be written
so that they don't apply to any future version of the OS, if we have any
hope at all that the vendor will eventually fix it. If the OS gets fixed,
the test will automatically happen again; if a new version of the OS is
released, and is still broken, we would have to update the test, but could
then prod the vendor that this is an issue.
While agree in principle, this late in code freeze, I'm happy for that
patch to applies as-is (i.e. skip those tests if $^O eq 'dragonfly',
regardless of version).

Go for it.

@p5pRT
Copy link
Author

p5pRT commented May 1, 2018

From @iabyn

On Mon, Apr 30, 2018 at 11​:53​:43PM +0300, Sawyer X wrote​:

On 04/30/2018 03​:27 PM, Dave Mitchell wrote​:

On Tue, Apr 24, 2018 at 02​:18​:15PM -0600, Karl Williamson wrote​:

On 04/24/2018 12​:37 PM, James E Keenan via RT wrote​:

On Sun, 22 Apr 2018 22​:07​:52 GMT, me@​xenu.pl wrote​:

The patch is attached.
Available for smoke-testing in​:
smoke-me/jkeenan/xenu/133141-dragonfly

I support adding skips to tests during the freeze which fix failing smokes.
The changes are isolated to the particular .t, and don't affect the
functioning of the actual interpreter.

But I'm thinking that skips for OS bugs, like this, should have be written
so that they don't apply to any future version of the OS, if we have any
hope at all that the vendor will eventually fix it. If the OS gets fixed,
the test will automatically happen again; if a new version of the OS is
released, and is still broken, we would have to update the test, but could
then prod the vendor that this is an issue.
While agree in principle, this late in code freeze, I'm happy for that
patch to applies as-is (i.e. skip those tests if $^O eq 'dragonfly',
regardless of version).

Go for it.

Now applied as v5.27.11-25-g02bf4969b4

--
Fire extinguisher (n) a device for holding open fire doors.

@jkeenan
Copy link
Contributor

jkeenan commented Feb 3, 2020

@xenu,

In May 2018, we applied this patch from you to skip 4 tests in PathTools t/cwd_enoent.t on DragonflyBSD. Discussion suggested that at some point we might be able to relax that skip condition.

Can we remove the 'skip'?

And, while we're talking about Dragonfly -- are you in a position to submit smoke-test reports on blead on this platform?

Thank you very much.
Jim Keenan

@tonycoz
Copy link
Contributor

tonycoz commented Oct 21, 2020

Can we remove the 'skip'?

It doesn't look like it:

$ git diff ../dist/PathTools/t/cwd_enoent.t | cat
diff --git a/dist/PathTools/t/cwd_enoent.t b/dist/PathTools/t/cwd_enoent.t
index 510c65ed0c..b0bf11ae2a 100644
--- a/dist/PathTools/t/cwd_enoent.t
+++ b/dist/PathTools/t/cwd_enoent.t
@@ -26,8 +26,8 @@ foreach my $type (qw(regular perl)) {
            if $type eq "perl" &&
                !(($Config{prefix} =~ m/\//) && $^O ne "cygwin");

-       skip "getcwd() doesn't fail on non-existent directories on this platfor\
m", 4
-           if $type eq 'regular' && $^O eq 'dragonfly';
+       #skip "getcwd() doesn't fail on non-existent directories on this platfo\
rm", 4
+       #    if $type eq 'regular' && $^O eq 'dragonfly';

        no warnings "redefine";
        local *Cwd::abs_path = \&Cwd::_perl_abs_path if $type eq "perl";
$ ./perl harness ../dist/PathTools/t/cwd_enoent.t 
../dist/PathTools/t/cwd_enoent.t .. 1/8
#   Failed test 'regular getcwd result on non-existent directory'
#   at t/cwd_enoent.t line 39.
#          got: '/tmp/TecsIaSgYF/testdir'
#     expected: undef

#   Failed test 'regular getcwd errno on non-existent directory'
#   at t/cwd_enoent.t line 40.
# Got errno code 0, expected 2, 70

#   Failed test 'regular abs_path result on non-existent directory'
#   at t/cwd_enoent.t line 45.
#          got: '/tmp/TecsIaSgYF/testdir'
#     expected: undef

#   Failed test 'regular abs_path errno on non-existent directory'
#   at t/cwd_enoent.t line 46.
# Got errno code 0, expected 2, 70
# Looks like you failed 4 tests of 8.
../dist/PathTools/t/cwd_enoent.t .. Dubious, test returned 4 (wstat 1024, 0x400)
Failed 4/8 subtests

Test Summary Report
-------------------
../dist/PathTools/t/cwd_enoent.t (Wstat: 1024 Tests: 8 Failed: 4)
  Failed tests:  1-4
  Non-zero exit status: 4
Files=1, Tests=8,  0 wallclock secs ( 0.00 usr  0.00 sys +  0.05 cusr  0.01 csys =  0.06 CPU)
Result: FAIL
$ uname -a
DragonFly  5.8-RELEASE DragonFly v5.8.3-RELEASE #10: Thu Sep 24 19:19:45 EDT 2020     root@www.shiningsilence.com:/usr/obj/home/justin/release/5_8/sys/X86_64_GENERIC  x86_64

The test passes with the skip in place.

Carlos started smokng dragonfly at some point, which is showing other errors, which I'm following up.

Unfortunately getting a dragonfly bug reporting account isn't a simple web sign-up :-(

@xenu
Copy link
Member

xenu commented Oct 22, 2020

Carlos started smokng dragonfly at some point, which is showing other errors, which I'm following up.

I think those failures are filesystem-related. On my UFS VM tests are 100% passing, so it's probably due to Carlos using HAMMER1 or HAMMER2.

@tonycoz
Copy link
Contributor

tonycoz commented Nov 1, 2020

@jkeenan
Copy link
Contributor

jkeenan commented Feb 11, 2021

To the extent that we are getting smoke-test results from Dragonfly BSD, they are running green. So I believe this ticket is closable. Anyone disagree?

Thank you very much.
Jim Keenan

@jkeenan jkeenan added the Closable? We might be able to close this ticket, but we need to check with the reporter label Feb 11, 2021
@tonycoz tonycoz self-assigned this Feb 15, 2021
@tonycoz
Copy link
Contributor

tonycoz commented Feb 15, 2021

I'll PR some checks to only skip on the broken releases

@tonycoz
Copy link
Contributor

tonycoz commented Feb 15, 2021

There hasn't been a release number bump yet, so we can't differentiate between the fixed and unfixed versions

@xenu xenu removed the Severity Low label Dec 29, 2021
@jkeenan
Copy link
Contributor

jkeenan commented Jul 11, 2022

There hasn't been a release number bump yet, so we can't differentiate between the fixed and unfixed versions

@tonycoz, has there been a release such that this is now closable?

@tonycoz
Copy link
Contributor

tonycoz commented Jul 12, 2022

yes, I'll check the for the release it ended up in and update the test

@iabyn
Copy link
Contributor

iabyn commented Jul 25, 2022

That fix is producing a warning on OSes that don't have exactly two numeric components. It's fixed it up with v5.37.2-10-gf9757a510d

@atoomic
Copy link
Member

atoomic commented Jul 25, 2022

The fixup in blead is provided by f9757a5

@jkeenan
Copy link
Contributor

jkeenan commented Jul 25, 2022

That fix is producing a warning on OSes that don't have exactly two numeric components. It's fixed it up with v5.37.2-10-gf9757a510d

Would it be possible to provide URLs to smoke-test reports that (i) show the warning and then (ii) show that the warning is no longer being generated?

@jkeenan jkeenan reopened this Jul 25, 2022
@tonycoz
Copy link
Contributor

tonycoz commented Apr 11, 2023

Does this still need to be open?

@jkeenan
Copy link
Contributor

jkeenan commented Oct 26, 2023

Does this still need to be open?

We haven't heard anything from the OP warranting keeping the ticket open, so I'm closing it now. Thanks.

@jkeenan jkeenan closed this as completed Oct 26, 2023
@jkeenan jkeenan removed the Closable? We might be able to close this ticket, but we need to check with the reporter label Oct 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants