Error messages for shared libraries for other platform
Here are my experiences in accidently getting a .so/.dll file for the wrong chip/CPU type: Windows: %1 is not a valid Win32 application *nix/Android: A long message about improper memory mappings and such. I'd like to propose the concept of better errors in these cases. Both Windows and Posix errors is this case are horrible, and it'd be nice for them to actually be written in English. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Do you know how to fix this? On Sunday, August 4, 2013, Ryan wrote:
Here are my experiences in accidently getting a .so/.dll file for the wrong chip/CPU type:
Windows:
%1 is not a valid Win32 application
*nix/Android:
A long message about improper memory mappings and such.
I'd like to propose the concept of better errors in these cases. Both Windows and Posix errors is this case are horrible, and it'd be nice for them to actually be written in English. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-- --Guido van Rossum (on iPad)
I don't really know C. At all. I was thinking the errors could be caught at a higher level, something like(the code isn't runnable): except windowserror as ex: if ex.string == '%1 is not...: raise_error_here Guido van Rossum <guido@python.org> wrote:
Do you know how to fix this?
On Sunday, August 4, 2013, Ryan wrote:
Here are my experiences in accidently getting a .so/.dll file for the wrong chip/CPU type:
Windows:
%1 is not a valid Win32 application
*nix/Android:
A long message about improper memory mappings and such.
I'd like to propose the concept of better errors in these cases. Both Windows and Posix errors is this case are horrible, and it'd be nice for them to actually be written in English. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-- --Guido van Rossum (on iPad)
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
(I have only had this happen with an improper DLL for the main Python executable, don't know about extension modules) The problem is, these errors tend to happen to the main Python executable, as it's code and the code contained in shared libraries are being loaded into memory. Because of this, there is no easy way to catch these errors, as they happen *before* Python is fully initialized and running. The only way I can think of to fix this would be to have a pre-script or program run the Python executable as a subprocess, and analyze stdout for these errors. Another solution would be to have a troubleshooting page at python.org explaining these errors. "The trouble with having an open mind, of course, is that people will come along and insist of putting things in it." - Terry Pratchett I don't really know C. At all. I was thinking the errors could be caught at a higher level, something like(the code isn't runnable): except windowserror as ex: if ex.string == '%1 is not...: raise_error_here Guido van Rossum <guido@python.org> wrote:
Do you know how to fix this?
On Sunday, August 4, 2013, Ryan wrote:
Here are my experiences in accidently getting a .so/.dll file for the wrong chip/CPU type:
Windows:
%1 is not a valid Win32 application
*nix/Android:
A long message about improper memory mappings and such.
I'd like to propose the concept of better errors in these cases. Both Windows and Posix errors is this case are horrible, and it'd be nice for them to actually be written in English. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity. _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
These errors are referring to extension modules. i.e. LLVMPy, the wrong TkInter(I accidentally installed Python 32-bit on top of Python 64-bit), and stuff like that. Clay Sweetser <clay.sweetser@gmail.com> wrote:
(I have only had this happen with an improper DLL for the main Python executable, don't know about extension modules) The problem is, these errors tend to happen to the main Python executable, as it's code and the code contained in shared libraries are being loaded into memory. Because of this, there is no easy way to catch these errors, as they happen *before* Python is fully initialized and running. The only way I can think of to fix this would be to have a pre-script or program run the Python executable as a subprocess, and analyze stdout for these errors. Another solution would be to have a troubleshooting page at python.org explaining these errors.
"The trouble with having an open mind, of course, is that people will come along and insist of putting things in it." - Terry Pratchett I don't really know C. At all. I was thinking the errors could be caught at a higher level, something like(the code isn't runnable):
except windowserror as ex: if ex.string == '%1 is not...: raise_error_here
Guido van Rossum <guido@python.org> wrote:
Do you know how to fix this?
On Sunday, August 4, 2013, Ryan wrote:
Here are my experiences in accidently getting a .so/.dll file for
the
wrong chip/CPU type:
Windows:
%1 is not a valid Win32 application
*nix/Android:
A long message about improper memory mappings and such.
I'd like to propose the concept of better errors in these cases. Both Windows and Posix errors is this case are horrible, and it'd be nice for them to actually be written in English. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
I suspect that on most platforms, we just get a NULL return from dlopen, call dlerror, and use the error string it returns. A quick test on OS X seems to bear that out. So, short of parsing the dlerror string (or trying to parse the elf/mach-o/etc. headers ourselves), I'm not sure what we could do. Sent from a random iPhone On Aug 4, 2013, at 23:01, Ryan <rymg19@gmail.com> wrote:
I don't really know C. At all. I was thinking the errors could be caught at a higher level, something like(the code isn't runnable):
except windowserror as ex: if ex.string == '%1 is not...: raise_error_here
Guido van Rossum <guido@python.org> wrote:
Do you know how to fix this?
On Sunday, August 4, 2013, Ryan wrote:
Here are my experiences in accidently getting a .so/.dll file for the wrong chip/CPU type:
Windows:
%1 is not a valid Win32 application
*nix/Android:
A long message about improper memory mappings and such.
I'd like to propose the concept of better errors in these cases. Both Windows and Posix errors is this case are horrible, and it'd be nice for them to actually be written in English. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity. _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
Well, the error seems to follow this pattern: ImportError: Cannot load library: loadsegments[number]: *number* cannot map segment from `library.so` at ... On Windows, it always says '%1 is not a valid Win32 application' So, could you catch the exceptions and compare the string or perform a regex match or the like? Andrew Barnert <abarnert@yahoo.com> wrote:
I suspect that on most platforms, we just get a NULL return from dlopen, call dlerror, and use the error string it returns. A quick test on OS X seems to bear that out. So, short of parsing the dlerror string (or trying to parse the elf/mach-o/etc. headers ourselves), I'm not sure what we could do.
Sent from a random iPhone
On Aug 4, 2013, at 23:01, Ryan <rymg19@gmail.com> wrote:
I don't really know C. At all. I was thinking the errors could be caught at a higher level, something like(the code isn't runnable):
except windowserror as ex: if ex.string == '%1 is not...: raise_error_here
Guido van Rossum <guido@python.org> wrote:
Do you know how to fix this?
On Sunday, August 4, 2013, Ryan wrote:
Here are my experiences in accidently getting a .so/.dll file for
the wrong chip/CPU type:
Windows:
%1 is not a valid Win32 application
*nix/Android:
A long message about improper memory mappings and such.
I'd like to propose the concept of better errors in these cases.
Both Windows and Posix errors is this case are horrible, and it'd be nice for them to actually be written in English.
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity. _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
On Mon, Aug 5, 2013 at 4:58 PM, Ryan <rymg19@gmail.com> wrote:
Well, the error seems to follow this pattern:
ImportError: Cannot load library: loadsegments[number]: *number* cannot map segment from `library.so` at ...
On Windows, it always says '%1 is not a valid Win32 application'
…unless you have Windows in a language that is not English.
So, could you catch the exceptions and compare the string or perform a regex match or the like?
No. Unless you wanted to hard-code all translations of this message. Or find an API to identify this message. -- Chris “Kwpolska” Warrick <http://kwpolska.tk> PGP: 5EAAEA16 stop html mail | always bottom-post | only UTF-8 makes sense
Each of the major *nix ldd/dyld families has a different set of errors, each one has half a dozen or more errors in its set, and most of them are localized. And usually the string you get back is dynamically generated by concatenating multiple different strings together. Let's take an example. You try to import foo.so. The module itself is fine, but it depends on libfoo.dylib. You happen to have three copies of libfoo.dylib on the path, but one is too old a version of libfoo to meet the requirement, while the next is an i386/ppc fat binary when you need x86_64, and the third is not a mach-o library at all. So, you get a four-line error message explaining that foo.so couldn't be opened because no valid libfoo image could be found, and then explaining what was wrong with each libfoo candidate. The explanations will be different between OS X 10.6 vs. 10.7-8, between English and German, etc., and completely unrelated to the messages on Linux or FreeBSD. Besides all the parsing problems, how do you want that to appear in Python in the end result? Sent from a random iPhone On Aug 5, 2013, at 7:58, Ryan <rymg19@gmail.com> wrote:
Well, the error seems to follow this pattern:
ImportError: Cannot load library: loadsegments[number]: *number* cannot map segment from `library.so` at ...
No, that's one of a dozen or so different errors you can get on recent Linux/gnu ldd in English.
On Windows, it always says '%1 is not a valid Win32 application'
So, could you catch the exceptions and compare the string or perform a regex match or the like?
Andrew Barnert <abarnert@yahoo.com> wrote:
I suspect that on most platforms, we just get a NULL return from dlopen, call dlerror, and use the error string it returns. A quick test on OS X seems to bear that out. So, short of parsing the dlerror string (or trying to parse the elf/mach-o/etc. headers ourselves), I'm not sure what we could do.
Sent from a random iPhone
On Aug 4, 2013, at 23:01, Ryan <rymg19@gmail.com> wrote:
I don't really know C. At all. I was thinking the errors could be caught at a higher level, something like(the code isn't runnable):
except windowserror as ex: if ex.string == '%1 is not...: raise_error_here
Guido van Rossum <guido@python.org> wrote:
Do you know how to fix this?
On Sunday, August 4, 2013, Ryan wrote:
Here are my experiences in accidently getting a .so/.dll file for the wrong chip/CPU type:
Windows:
%1 is not a valid Win32 application
*nix/Android:
A long message about improper memory mappings and such.
I'd like to propose the concept of better errors in these cases. Both Windows and Posix errors is this case are horrible, and it'd be nice for them to actually be written in English. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity. _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
On Mon, Aug 5, 2013, at 2:01, Ryan wrote:
if ex.string == '%1 is not...:
ex.winerror == 193, surely. The message probably differentiates by locale, and doing this kind of thing is fragile. For your POSIX case, it looks like the underlying error (likely errno == ENOEXEC) is being caught and wrapped up in an ImportError at some lower level, which apparently isn't being done on windows for whatever reason. So maybe this code should A) have an analogous version written on windows and B) have a more clear error message It's possible that either or both of these cases can't distinguish between attempting to load a library of the wrong architecture, and simply loading a file that is corrupt or simply not a DLL/.so file at all. Have you tried doing so? It _might_ still be a common enough case to be worthwhile to go fishing for evidence that it's the case after getting a generic error that could be that or could be something else, but that's different from just unconditionally rewriting the error message.
On Mon, Aug 5, 2013, at 1:07, Ryan wrote:
Here are my experiences in accidently getting a .so/.dll file for the wrong chip/CPU type:
Windows:
%1 is not a valid Win32 application
There's got to be some way to fill in %1 with the name of the dll. But a look through the list of all windows error messages on my system shows a bunch with %values that the caller could not possibly know.
participants (6)
-
Andrew Barnert -
Chris “Kwpolska” Warrick -
Clay Sweetser -
Guido van Rossum -
random832＠fastmail.us -
Ryan