Program fails at pyiboot01_bootstrap when using --noconsole
#4213
Comments
|
I am experiencing similar issues to this. Any updates? |
|
I'm seeing a similar issue while trying to freeze SubDownloader. This is on: PyInstaller 3.5, cpython 3.7.4 and using PyQt5 5.13.0 |
|
I managed to reduce the problem. Create the following 2 files: projectname.py projectname/__init__.py Then execute pyinstaller: The resulting When copying projectname.py to projectname2.py and running pyinstaller on that file, the resulting exe works fine (apart from it being a cli app packaged as a windowed app). |
|
I also ran in to this issue, and my python script doesn't have the same name as they python module. I have set debug=True. I am not getting any errors when running with console=True. When I run with console=False, there is no useful error messages, just like @cdgriffith reported. Is there any method to get better debug output? |
|
|
|
I'm also facing this problem on some Windows 7 and Windows 10 computers. |
I solved the problem in my case downgrading both Python to 3.6.8 and PyInstaller to 3.4. |
|
@htgoebel I would like to help try to solve this during my winter break. Do you have any pointers on methods to debug issues when running with --console causes the issue to go away? I have of course gone through the When Things Go Wrong a few times. |
|
My current plan is to modify the bootloader to display the traceback information using PyErr_Fetch when the pyiboot01_bootstrap message is displayed. In order to accomplish this, I have submitted two PRs which fix bootloader building in MSYS2. We'll see if I can make this work. |
|
Better error reporting is always a big win. |
|
My plan worked, I was able to successfully extract a traceback, which gave me the following error: With the traceback, I was able to quickly determine that I had an issue in my spec file, I was passing the following run-time option: This was my mistake and it was a simple fix once I knew what the error was. I was getting an AttributeError because PyInstaller was trying to write a message to stderr each time a module was loaded. Since I was running in --windowed, sys.stderr was set to None, and writing to stderr was raising an AttributeError. Since some of the others who have the same error message are directly executing using the command arguments instead of a spec file, this doesn't sound like it related - unless PyInstaller is itself configuring with this option. Two things that could be improved here:
If anyone wants to play with the Tracebacks enabled, you can use my branch: You will need to build the bootloader to make use of it. I will work on trying to make a proper PR using these updates, but this will be more work. I am using the Python 3.3+ C-API for Python, so I will need to dig in to more how PyInstaller makes use of the API to support Python 2.7 as well and try make the traceback functionality more atomic so that it can be used to capture all Python errors in the bootloader. |
Adds the Python traceback information to debug errors during pyiboot01_bootstrap when running in Windows in windowed mode. This will allow debugging errors like in Issue pyinstaller#4213. Signed-off-by: Dan Yeaw <dyeaw@ford.com>
Adds the Python traceback information to debug errors during pyiboot01_bootstrap when running in Windows in windowed mode. This will allow debugging errors like in Issue pyinstaller#4213. Signed-off-by: Dan Yeaw <dyeaw@ford.com>
|
I created PR #4259. In order to get the full traceback you need to run with |
When running in Windows in windowed mode, the debug bootloader will now show the Python traceback information. This help debuging errors during pyiboot01_bootstrap. This will allow debugging errors like in Issue pyinstaller#4213. For showing the sorce lines, the aplication needs frozen with ``--noarchive``. Signed-off-by: Dan Yeaw <dyeaw@ford.com>
When running in Windows in windowed mode, the debug bootloader will now show the Python traceback information. This help debuging errors during pyiboot01_bootstrap. This will allow debugging errors like in Issue pyinstaller#4213. For showing the sorce lines, the aplication needs frozen with ``--noarchive``. Signed-off-by: Dan Yeaw <dyeaw@ford.com>
When running in Windows in windowed mode, the debug bootloader will now show the Python traceback information. This help debuging errors during pyiboot01_bootstrap. This will allow debugging errors like in Issue pyinstaller#4213. For showing the source lines, the application needs to be frozen with ``--noarchive``. Signed-off-by: Dan Yeaw <dyeaw@ford.com>
Legorooj
added
area:bootloader
When running in Windows in windowed mode, the debug bootloader will now show the Python traceback information. This help debuging errors during pyiboot01_bootstrap. This will allow debugging errors like in Issue pyinstaller#4213. For showing the source lines, the application needs to be frozen with ``--noarchive``. Signed-off-by: Dan Yeaw <dyeaw@ford.com>
When running in Windows in windowed mode, the debug bootloader will now show the Python traceback information. This help debuging errors during pyiboot01_bootstrap. This will allow debugging errors like in Issue #4213. For showing the source lines, the application needs to be frozen with ``--noarchive``. Signed-off-by: Dan Yeaw <dyeaw@ford.com>
|
I am also facing this problem on Windows10 64bit Solvoed after downgrading Pyinstaller to 3.5. |
When running in Windows in windowed mode, the debug bootloader will now show the Python traceback information. This help debuging errors during pyiboot01_bootstrap. This will allow debugging errors like in Issue pyinstaller#4213. For showing the source lines, the application needs to be frozen with ``--noarchive``. Signed-off-by: Dan Yeaw <dyeaw@ford.com>
|
Seems like this issue is still lurking.
Everything works correctly and forms a running application when dropping |
|
#4213 (comment) might to be the key:
|
|
Hello. Thank you very much, |
|
I had this issue as well with pyinstaller 4.0, but using this comment I have found a solution. The command |
tried this, but now the error is Error : Just to mention that my script on start checks for some os details on start using subprocess.check_output("") |
|
I have the same problem with Python 3.9.1 and PyInstaller 4.1 on Windows 10. -- windowed --onefile : problem If I replace runw_d.exe with run_d.exe, there is no issue (of course console appears). I think windowed bootloader has some issue with MS Windows. |
Thank you, that worked for me. |
The `FrozenImporter` in `pymod03_importers` uses `trace()` function if `sys.flags.verbose` is enabled to trace the imports to `sys.stderr`. This results in the following error: `Failed to execute script pyiboot01_bootstrap` when `sys.stderr` is unavailable (is `None`), which happens on Windows when windowed bootloader is used in combination with `sys.flags.verbose` enabled (i.e., `--debug imports` or `--debug all` is passed on the command-line). The problem is that while `pyiboot01_bootstrap` does install its `NullWriter` for `sys.stderr` when the latter is unavailable, that happens too late; there is an `import os` that happens between the end of bootstrap process (the `pyimod03_importers.install()` call) and monkey-patching `NullWriter()` into `sys.stderr`. While the problem could also be fixed by moving the `NullWriter` initialization before the offending import, simply disabling the `trace()` function seems a better option. Fixes pyinstaller#4213.
The `FrozenImporter` in `pymod03_importers` uses `trace()` function if `sys.flags.verbose` is enabled to trace the imports to `sys.stderr`. This results in the following error: `Failed to execute script pyiboot01_bootstrap` when `sys.stderr` is unavailable (is `None`), which happens on Windows when windowed bootloader is used in combination with `sys.flags.verbose` enabled (i.e., `--debug imports` or `--debug all` is passed on the command-line). The problem is that while `pyiboot01_bootstrap` does install its `NullWriter` for `sys.stderr` when the latter is unavailable, that happens too late; there is an `import os` that happens between the end of bootstrap process (the `pyimod03_importers.install()` call) and monkey-patching `NullWriter()` into `sys.stderr`. While the problem could also be fixed by moving the `NullWriter` initialization before the offending import, simply disabling the `trace()` function seems a better option. Fixes #4213.
|
pyinstaller/PyInstaller/building/makespec.py Line 440 in 35103b3 |
That didn't work for me. It looks like the search continues. PyInstaller is not working in PyCharm for me at all. I get the following error when wunning that line (with my program name obviously): And this issue is CLOSED! Fantastic. Well, I guess it's web development for me then LOL |
|
@Carewen please open a new issue; we can help there. |
Entering a new issue is quite a bit of heavy lifting. Particularly for a known issue that has workarounds I've tried that do not work. I'll have a go but I'm less than month into working with Python and I suspect it's going to take me a while to complete the issue submission. |
|
It's very likely not the same bug, which is why I'm asking you to open a new one. |
Python 3.6.8
Windows 10 Build 17763
Pyinstaller 3.4 / 3.5.dev0+06f7da789
I am having an odd issue where my executable is working just fine as long as there is a console enabled, but fails at
pyiboot01_bootstrapwhen there is not a console (which also really limits the amount of debug output I can gather.)I have tried running the
sxstraceas well, but it leaves an emptytrace.txtfile.Works the same in
--onedirand--onefile.As I am unsure of the root cause I am sorry I do not know how to limit the scope for a better example.
The code I am using is located https://github.com/cdgriffith/FastFlix/tree/44636c97036a5cd2d2ec05ce64b8a11f99e388c3
One time prep:
Build command for noconsole (broken version)
Working command with console
(Please note that even though it is not a venv this python version is specifically for building this project and keeping it the same as used on Appveyor, where the problem also occurs.)
Build output:
If there is anything else I can do or provide to make this easier to solve please let me know.
I did have to apply this fix to have the
--debugoption working, just in case that changes anything.Thank you for your time!
The text was updated successfully, but these errors were encountered: