libuv 1.26 update caused file change notification to be broken on macOS

[vrurg]

This is a follow-up report from rakudo/rakudo#3100. In brief: somewhere between rakudo 2019.03 and 2019.07 IO.watch stopped reporting file changes on macos. As surmised by @jnthn, the likely cause is a515819.

[ugexe]

If it is broke in libuv then nodejs should also be busted. If one can provide a nodejs example to the libuv folks I'm sure they'll be able to figure out what is up. I just wouldn't expect them to do anything with perl6 code/output.

[MasterDuke17]

libuv is currently at 1.32.0. Nothing stands out in a quick glance at the change log, but maybe we should try another update?

…

Sent from my iPhone

On Sep 18, 2019, at 7:11 PM, Vadim Belman ***@***.***> wrote: This is a follow-up report from rakudo/rakudo#3100. In brief: somewhere between rakudo 2019.03 and 2019.07 IO.watch stopped reporting file changes on macos. As surmised by @jnthn, the likely cause is a515819. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[vrurg]

BTW, Raku/roast#576 has a test for the case. I don't want to merge it though until the problem is resolved.

[jnthn]

As surmised by @jnthn, the likely cause is a515819.

Just to be clear: I identified that as the only libuv bump, but I've not tried running things before/after it. It'd be helpful if somebody on MacOS could run things on that commit and its parent and see if it changes anything.

[bduggan]

Just copying my comment from rakudo/rakudo#3100 (comment) to here:

I downgraded to the commit right before that one, and rebuilt (also downgrading nqp and rakudo to versions such that the deps were satisfied) -- and can report that it did not fix the issue -- i.e. this version still failed :

This is Rakudo version 2019.03.1-410-ge0076423c built on MoarVM version 2019.05-26-gc63e7eb7a
implementing Perl 6.d.

The moarvm,nqp, and rakudo commits to which I downgraded were respectively -- c63e7eb , Raku/nqp@6372077 and rakudo/rakudo@e007642

Here's the output, of running 2019.03.1 (which works), and the above (which doesn't) --

$ cat runme.p6
react whenever 'watchme'.IO.watch -> $e {
  say "got an event: " ~ $e
}
$ perl6 -v
This is Rakudo version 2019.03.1 built on MoarVM version 2019.03
implementing Perl 6.d.
$ perl6 runme.p6
got an event: IO::Notification::Change<140480293651968>
got an event: IO::Notification::Change<140480293652928>
got an event: IO::Notification::Change<140480293652976>
^C
$ ~/p6-dev/rakudo/perl6 -v
This is Rakudo version 2019.03.1-410-ge0076423c built on MoarVM version 2019.05-26-gc63e7eb7a
implementing Perl 6.d.
$ ~/p6-dev/rakudo/perl6 ./runme.p6
^C
$

[jnthn]

I downgraded to the commit right before that one, and rebuilt (also downgrading nqp and rakudo to versions such that the deps were satisfied)

Just in case: the libuv comes from a submodule in 3rdparty; I don't know if a manual step is needed to make sure that is sync'd if checking out an earlier commit, but maybe a git submodule sync or so after doing the checkout would be required to actually build the older version of libuv.

[jnthn]

I also just did a git log -p 2019.03..a515819 src/io/ in case anything stood out, but nothing did.

[bduggan]

Just in case: the libuv comes from a submodule in 3rdparty; I don't know if a manual step is needed to make sure that is sync'd if checking out an earlier commit, but maybe a git submodule sync or so after doing the checkout would be required to actually build the older version of libuv.

I re-ran Configure.pl which does a git submodule sync, so it looked like that took care of it :-)

[vrurg]

@bduggan you can make sure that submodules differ by checking hash of git submodule status command.

[bduggan]

 git submodule status
 3c5a72eb57bf662c5f9e353d5a3856185a82a35e 3rdparty/cmp (v18-3-g3c5a72e)
 deade9aa64b1b101d01ca69bd8e335da72e9dfc3 3rdparty/dynasm (remotes/origin/debug-dasm-9-gdeade9a)
 1dabd7c2fd438920502c85eaf9ca4212d722c4b5 3rdparty/dyncall (1dabd7c)
 6210090ba8b0d8efcb4b532cc05cb3375ec7ad2e 3rdparty/libatomicops (heads/master)
 289e346bb9b968377ffbbbe6876342fedda4e072 3rdparty/libtommath (v1.0-rc2-15-g289e346)
 8669d8d3e93cddb62611b267ef62a3ddb5ba3ca0 3rdparty/libuv (v1.26.0)

[vrurg]

The problem clearly tracks down to libuv 1.26, commit 62b5816. Here is the proof following.

I bisected it using the test in Raku/roast#576. The bisect came up with:

[... skipped ...]
# good: [4ffb4082b04a87cdddca098bad0089d943651942] Make Failure.list also throw
git bisect good 4ffb4082b04a87cdddca098bad0089d943651942
# bad: [fc4aca08f7c36475a63218d91c88420bee522c4e] Bump NQP_REVISION
git bisect bad fc4aca08f7c36475a63218d91c88420bee522c4e
# first bad commit: [fc4aca08f7c36475a63218d91c88420bee522c4e] Bump NQP_REVISION

The bump brought in commit d159067. libuv update to 1.26 precedes it by just two commits – 62b5816. Then it's was pure technical test. I take last known good Rakudo commit from bisect ( rakudo/rakudo@4ffb4082b – actually the bad one follows it immediately), then Raku/nqp@da96d399a which is referred by Rakudo at this point. Then I compile everything against the suspected 62b5816 and against immediately preceding 5e36339 which contains libuv v1.23 (that's what the last log entry in the commit says).

Here is the results:

⇒ ./perl6-m -v                                                                                            23-09-19 22:18:50
This is Rakudo version 2019.03-40-g4ffb4082b built on MoarVM version 2019.03-31-g6c7810ce7
implementing Perl 6.d.
⇒ ./perl6-m -Ilib ../rakudo/t/spec/S16-io/watch.t                                                         23-09-19 22:18:48
1..1
ok 1 - all watch events received

⇒ ./perl6-m -v                                                                                            23-09-19 22:20:10
This is Rakudo version 2019.03-40-g4ffb4082b built on MoarVM version 2019.03-31-g6c7810ce7
implementing Perl 6.d.
⇒ ./perl6-m -Ilib ../rakudo/t/spec/S16-io/watch.t                                                         23-09-19 22:20:13
1..1
not ok 1 - all watch events received
# Failed test 'all watch events received'
# at ../rakudo/t/spec/S16-io/watch.t line 41
# expected: '10'
#      got: '0'
# Looks like you failed 1 test of 1

So far, the prime suspect is likely to be libuv 1.25 with the following changelog entry:

* fsevents: really watch files with fsevents on macos 10.7+ (Jameson Nash)

But this is just my guess so far.

[vrurg]

UPD After building 0a9ccb1 with different versions of libuv I can finally approve that the problematic version is 1.25, the prime suspect is libuv/libuv@2d2af382ce84b91d.

Unfortunately, I won't be able to golf a piece code suitable for a ticket on libuv repository until at least after tomorrow. Besides, I never used libuv before (not to mention the long break up with C itself). So, if somebody is willing to help with this I would very much appreciate it!

[ugexe]

You could try a node that uses a broken libuv. A 1 liner using fs.watch should be pretty similar to perl6

…

On Mon, Sep 23, 2019 at 9:50 PM Vadim Belman ***@***.***> wrote: *UPD* After building 0a9ccb1 <0a9ccb1> with different versions of libuv I can finally approve that the problematic version is 1.25, the prime suspect is ***@***.*** <libuv/libuv@2d2af382ce84b91d>. Unfortunately, I won't be able to golf a piece code suitable for a ticket on libuv repository until at least after tomorrow. Besides, I never used libuv before (not to mention the long break up with C itself). So, if somebody is willing to help with this I would very much appreciate it! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1178?email_source=notifications&email_token=AAB2RBBZM66YNIQREFPYSNTQLF6BDA5CNFSM4IYCCCT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7M4KDA#issuecomment-534365452>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB2RBAMSLIC6EOBIPU2XATQLF6BDANCNFSM4IYCCCTQ> .

[vrurg]

Got some time on fresh air today to report the bug on libuv/libuv#2488. It turns out that it's easier to revivify the remains of old C wisdom than to find out which libuv version node is using.

[vrurg]

libuv/libuv@97b85e8 workarounds the bug. Makes sense bumping libuv to the next version when available.

[dogbert17]

Version 1.33 is now out. Can someone with a Mac give it a whirl?

https://github.com/libuv/libuv/blob/v1.x/ChangeLog

[vrurg]

@dogbert17 Manual checkout of 3rdparty/libuv v1.33.0 tag, test from Raku/roast#576 – passing. Cross-check with rakudo 2019.07.1 predictably fails.

From the point of view of this ticket 1.33.0 is good to go.

[dogbert17]

Fixed with eebe39b