This appears to be a MoarVM specific issue: I can’t get this script to fail on the JVM backend.
The applicable code appears to be MVM_dir_read in src/io/dirops.c . Which appears to take a thread context. On non-Win32 systems, it appears to be using readdir_r() . For which I found a rather recent: https://github.com/h2o/h2o/pull/1046 https://github.com/h2o/h2o/pull/1052 So it would appear we need to replace readdir_r by readdir? > On 10 Oct 2016, at 17:58, Sam S. (via RT) <perl6-bugs-follo...@perl.org> > wrote: > > # New Ticket Created by Sam S. > # Please include the string: [perl #129845] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=129845 > > > > Calling `.dir` concurrently from multiple threads, results in some of > the IO::Path objects it returns to be corrupted. > > Golfed test script that pretty reliably demonstrates the bug: > https://gist.github.com/smls/3c59b3f818d27f3854852afd361e9b95 > > The corruption presents itself in the fact that the .Str method on > such an IO::Path says it's one file, while its .gist (and other > methods) think it's another file, as exhibited by the following sample > output from the above script: > > Str: /tmp/concurrent_dir_bug/sss > absolute: /tmp/concurrent_dir_bug/vvv > gist: "/tmp/concurrent_dir_bug/vvv".IO > perl: "/tmp/concurrent_dir_bug/vvv".IO(:SPEC(IO::Spec::Unix)) > > The script almost always fails with an output like this (not always > with the same file names of course), but *sometimes* it fails with the > following error instead (where the line number points to the `await`): > > Type check failed in binding; expected Str but got Mu (Mu) > in block <unit> at /home/sam/dev/concurrent_dir_bug.p6 line 13 > > And *one* time I got the following instead: > > [1] 24237 segmentation fault (core dumped) ~/dev/test.p6 > > (It's possible that the latter two failure modes are just general > concurrency bugginess, possibly related to RT# 129781: > https://rt.perl.org/Ticket/Display.html?id=129781 )
