llvm dev - Mar 2021 - TempFile::keep() issue on WIndows

I think Windows 7 support is broken currently.

The bug report sounds like https://github.com/rust-lang/rust/issues/81051
See discussion in https://reviews.llvm.org/D81803

De : llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces
at lists.llvm.org>> De la part de Adrian McCarthy via llvm-dev
Envoyé : March 18, 2021 8:04 PM
À : Snider, Todd <t-snider at ti.com<mailto:t-snider at ti.com>>
Cc : llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Objet : Re: [llvm-dev] TempFile::keep() issue on WIndows

It's surprising (at least, to me) to get "permission denied" when
attempting GetFilePathNameByHandle.  It seems more likely that the function
failed to resolve the path for some other reason, and then the archiver tried to
do an operation to the file with the unresolved path, and _that_ step caused the
"permission denied."

But if it _is_ the GetFilePathNameByHandle, then I would guess that the file
handle is corrupted thus the request is about an object the process doesn't
have rights to access...

I don't have Windows 7 to try it out.

Does the file already exist?  If not, is it being created?  Is there anything
unusual about the path (e.g., is it longer than 256-ish characters long or
referencing a server over a network or contain characters outside of ASCII that
are possibly in the wrong encoding)?

If you're able to debug it at the point of the GetFilePathNameByHandle call,
can you check that the handle looks reasonable?  It should look like a valid
pointer (possibly just the lower 32-bits if you're on a 64-bit machine), so
0, 0xFFFFFFFF, and unaligned values would be suspicious.

Another common problem is that sometimes anti-malware scanners will briefly lock
a newly created file to scan it, which can cause a sharing violation.  Usually
these are intermittent because they're timing sensitive, but it might be
worth temporarily disabling your scanners to see if that makes the problem go
away.  If so, we can look at the access pattern and see if there's a less
fragile approach.

On Thu, Mar 18, 2021 at 4:12 PM Snider, Todd via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Hi All,

I’ve run into an issue trying to run an llvm-ar executable built on Windows 10
on a Windows 7 machine.

I get a permission denied error when the archiver tries to write the new archive
file:

%> llvm-ar rv mylib.lib foo.o
llvm-ar.exe: warning: creating mylib.lib
llvm-ar.exe: error: mylib.lib: permission denied

I’ve tracked the issue down to a call to ::GetFinalPathByHandle() from
realPathFromHandle() (defined in llvm/lib/Support/Windows/Path.inc).
realPathFromHandle() will set an error code when ::GetFinalPathByHandle()
returns a value of 0 (as it does in the above case).

Is there a known incompatibility/limitation/bug with trying to run the Windows
10 kernel version of GetFinalPathByHandle() on a Windows 7 machine?

~ Todd Snider


_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210319/a7cb2d45/attachment.html>

My personal view is that LLVM should officially drop support for Windows 7.
Windows 7 is end of life, as of February 2020, and AFAIK, we don't have any
build bots running Windows 7. As such, we can't guarantee that any changes
that are made will work on that version of Windows (D81803 being a case in
point). Similarly, most LLVM developers won't have access to such machines,
so won't be able to test fixes or reproduce bugs locally. As we move
forward, it is likely that more of these issues will crop up, and usually
won't be noticed until late on when some project imports a release branch
with a bug in.

On Fri, 19 Mar 2021 at 00:40, Alexandre Ganea via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I think Windows 7 support is broken currently.
>
>
>
> The bug report sounds like https://github.com/rust-lang/rust/issues/81051
>
> See discussion in https://reviews.llvm.org/D81803
>
>
>
> *De :* llvm-dev <llvm-dev-bounces at lists.llvm.org> *De la part de*
Adrian
> McCarthy via llvm-dev
> *Envoyé :* March 18, 2021 8:04 PM
> *À :* Snider, Todd <t-snider at ti.com>
> *Cc :* llvm-dev at lists.llvm.org
> *Objet :* Re: [llvm-dev] TempFile::keep() issue on WIndows
>
>
>
> It's surprising (at least, to me) to get "permission denied"
when
> attempting GetFilePathNameByHandle.  It seems more likely that the function
> failed to resolve the path for some other reason, and then the archiver
> tried to do an operation to the file with the unresolved path, and _that_
> step caused the "permission denied."
>
>
>
> But if it _is_ the GetFilePathNameByHandle, then I would guess that the
> file handle is corrupted thus the request is about an object the process
> doesn't have rights to access...
>
>
>
> I don't have Windows 7 to try it out.
>
>
>
> Does the file already exist?  If not, is it being created?  Is there
> anything unusual about the path (e.g., is it longer than 256-ish characters
> long or referencing a server over a network or contain characters outside
> of ASCII that are possibly in the wrong encoding)?
>
>
>
> If you're able to debug it at the point of the GetFilePathNameByHandle
> call, can you check that the handle looks reasonable?  It should look like
> a valid pointer (possibly just the lower 32-bits if you're on a 64-bit
> machine), so 0, 0xFFFFFFFF, and unaligned values would be suspicious.
>
>
>
> Another common problem is that sometimes anti-malware scanners will
> briefly lock a newly created file to scan it, which can cause a sharing
> violation.  Usually these are intermittent because they're timing
> sensitive, but it might be worth temporarily disabling your scanners to see
> if that makes the problem go away.  If so, we can look at the access
> pattern and see if there's a less fragile approach.
>
>
>
> On Thu, Mar 18, 2021 at 4:12 PM Snider, Todd via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi All,
>
>
>
> I’ve run into an issue trying to run an llvm-ar executable built on
> Windows 10 on a Windows 7 machine.
>
>
>
> I get a permission denied error when the archiver tries to write the new
> archive file:
>
>
>
> %> llvm-ar rv mylib.lib foo.o
>
> llvm-ar.exe: warning: creating mylib.lib
>
> llvm-ar.exe: error: mylib.lib: permission denied
>
>
>
> I’ve tracked the issue down to a call to ::GetFinalPathByHandle() from
> realPathFromHandle() (defined in llvm/lib/Support/Windows/Path.inc).
>
> realPathFromHandle() will set an error code when ::GetFinalPathByHandle()
> returns a value of 0 (as it does in the above case).
>
>
>
> Is there a known incompatibility/limitation/bug with trying to run the
> Windows 10 kernel version of GetFinalPathByHandle() on a Windows 7 machine?
>
>
>
> ~ Todd Snider
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210319/fea2e665/attachment.html>

On 3/18/21 5:40 PM, Alexandre Ganea via llvm-dev wrote:
> I think Windows 7 support is broken currently.
> 
> The bug report sounds like https://github.com/rust-lang/rust/issues/81051
> 
> See discussion in https://reviews.llvm.org/D81803
There is also https://bugs.llvm.org/show_bug.cgi?id=48378