I am building a fairly complex application using Python and PySide. Finally the day of the release is nearing so I want to build this application as an exe.
However, I have a strange problem on my hands. I’ve used PyInstaller (using version 2 by the way) in the past and never had this happened to me.
Basically, when I build the application with the --console flag, it works fine – but it opens the console window. When I build the application with the window flag (-w), it doesn’t work fine. It starts and everything, but there are all these weird glitches. For example, loading a text file often raises the BadFileDescriptor error (which doesn’t happen in console mode), and the application crashes after performing a certain task. What’s worse is that the task is a loop, and it performs fine the first time, but when it starts working again, it crashes.
When I looked at the minidump file there were some errors about memory access violation of QtGui4.dll file. Again, this doesn’t happen in console mode.
Anyone have any ideas?
The
BadFileDescriptorerror and the consequently memory access violation are caused by the fact that thestdoutof applications in windowed mode is a fixed size buffer.So, if you have are writing to
stdout, either withprintorsys.stdoutdirectly, after some time you’d see those errors.You can fix this by:
stdoutlogginginstead of printing to stdoutstdoutat the beginning of the execution of your application. This is the solution that requires less code to be changed, even though I think moving the debugging statements tologgingwould be the better choice.To redirect
stdoutyou can use this kind of code:Just before executing your program. You can use also some custom object to put the output in “log” files or whatever, the important thing is that the output should not fill the fixed size buffer.
For example you could do something like this to be able to take advantage of the
loggingmodule without changing too much code:The downside of this approach is that
printexecutes more calls tostdout.writefor each line:If you want you can probably avoid this kind of behaviour writing a real
writefunction that callsthe_logger.debugonly with “full lines”.Anyway I think these kind of solution should only be temporary, and be used only before porting the
prints to calls tologging.debug.(Obviously the loggers should write to a file and not to
stdoutto avoid the errors.)