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

Briefcase download an incomplete rcedit-x64.exe lead to "OSerror: [WinError 193] %1 is not a valid win32 application" #1160

Open
baozidai opened this issue Apr 1, 2023 · 3 comments
Labels
bug A crash or error in behavior.

Comments

@baozidai
Copy link

baozidai commented Apr 1, 2023

Describe the bug

The first time to run briefcase build, it downloads a file "rcedit-x64.exe" to path C:\Users<YourUsername>\AppData\Local\BeeWare\briefcase\Cache\tools (THE_TOOLS_PATH).

In some way, I get an incomplete one, so that I can't build my application. Then the problem is:
There is no way to make sure you get a healthy "rcedit-x64.exe", or if you get a bad one, the trackback don't show you any thing about "rcedit-x64.exe", and this is hard to know the real problem.

Steps to reproduce

  1. Make sure there is not a file "rcedit-x64.exe" or "rcedit-x64.exe" in THE_TOOLS_PATH above. If there is one, delete it.
  2. Create a new briefcase project
  3. Create scaffold via briefcase create
  4. Then briefcase build, it should not find the rcedit file and start downloading "rcedit-x64.exe". If your have a bad Internet, you can get an incomplete "rcedit-x64.exe" in THE_TOOLS_PATH.
  5. "OSerror: [WinError 193] %1 is not a valid win32 application" will occur.

Expected behavior

A perfect build process.

Screenshots

image

Environment

  • Operating System: Windows 10 21H2
  • Python version: 3.11.2
  • Software versions:
    • Briefcase: 0.3.13
    • Toga: 0.3.0

Logs

I've fixed this so I can't get a bug log.

Additional context

How to fix

if you're facing this, download a rcedit-x64.exe from rcedit. Replace it in C:\Users<YourUsername>\AppData\Local\BeeWare\briefcase\Cache\tools

@baozidai baozidai added the bug A crash or error in behavior. label Apr 1, 2023
@rmartin16
Copy link
Member

We put a mitigation in place to to prevent a partial tool download from persisting in the Briefcase tools cache.

Any time Briefcase fails, it puts the log file in to the logs directory of your project. If it is still available for the briefcase build run that did the download, I would appreciate you uploading here so we can understand what went wrong.

@baozidai
Copy link
Author

baozidai commented Apr 2, 2023

briefcase.2023_04_01-22_26_05.build.log (first it try to download the tool, but failed)
briefcase.2023_04_01-22_35_35.build.log (Next build, cause there is an incomplete one rcedit, OsError occur)

@rmartin16
Copy link
Member

Thank you, @baozidai; I appreciate the additional information. This helps me to understand a bit of what happened.

In the first log from 22:26:05, the download failure occurs from just attempting to setup the HTTPs connection with github.com and before actually downloading any data and before the rcedit-x64.exe file is created in the Briefcase cache in AppData.

In the 22:35:35 log file, though, you can see that an attempt is made to download rcedit-x64.exe again and after ~73 seconds, it ostensibly succeeds.....yet, when rcedit-x64.exe is used, Windows does not think it is a valid executable.

Given the download apparently averaged ~18KB/s and there was at least one previous failure to even connect to github.com, this certainly seems to be distressed connection...or one that is potentially being throttled. I'm not sure what the mechanism would be for a download to finish successfully....yet with different data than was requested; the underlying protocols use at least basic hashing for data integrity.

I think my most plausible guess is rcedit-x64.exe was not actually downloaded from github.com; perhaps something else entirely was returned (like a proxy redirection web page for instance) or perhaps the connection was interrupted but terminated properly somehow.

This does reveal that more can be done to verify the integrity or perhaps identity of the downloaded tools. Maybe even catching errors like this and asking the user if they want to "clear the tool cache" or something to see if that mitigates an error they're seeing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A crash or error in behavior.
Projects
None yet
Development

No branches or pull requests

2 participants