| msg125649 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2011-01-07 15:48 |
| When an extension could not be loaded, because it requires some DLL that is missing, Python shows the following error message: ImportError: DLL load failed: The specified module could not be found. It will help tremendously in debugging extension problems if the missing DLL name is specified in error message. |
|
|
| msg125651 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) *  |
Date: 2011-01-07 16:21 |
| Is it even possible? Each time I tried, the only solutions involved an external program like Dependency Walker. |
|
|
| msg125652 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2011-01-07 16:22 |
| I'm pretty sure we can't do this, if I understand your request. Say you have techtonik.pyd as your extension and it depends on foobar.dll. If we try to load techtonik.pyd and this pyd can't find or successfully load foobar.dll, Python doesn't know about *this* DLL. It just knows that it can't load techtonik.pyd, so that's what we'd be able to output, which isn't that helpful. |
|
|
| msg125653 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2011-01-07 16:23 |
| Agree with Amaury. depends has always been my solution to this type of problem. |
|
|
| msg125663 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2011-01-07 17:42 |
| Can you cross reference the part of code where this error is catched? Why Python can't get information about the reason .DLL is not loaded? Is it at least possible to add a hook point at the exact time the import fails to insert component that is able to inquiry system about this information (like depends)? |
|
|
| msg125665 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2011-01-07 17:47 |
| See _PyImport_GetDynLoadFunc in Python/dynload_win.c -- that's where this is happening. > Why Python can't get information about the reason .DLL is not loaded? Windows does not provide it in the case you are speaking of. If I call LoadLibraryEx for techtonik.pyd, either it succeeds because everything is there, or it fails because something is not there. We get no information about dependency hierarchies failing to load. |
|
|
| msg125668 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2011-01-07 17:53 |
| The code is in Python/dynload_win.c To load an extension module mymodule.pyd, Python calls LoadLibrary('/path/to/mymodule.pyd'); when it returns NULL, the code calls GetLastError() (which returns 126 in this case) then FormatMessage to get an error message. To get the full path to the .pyd, you can use imp.find_module(), but there is nothing else we can do I fear. |
|
|
| msg125682 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2011-01-07 18:59 |
| I see. But depends.exe dependency walker somehow finds the exact code that is failing, so there should be a way to do extra investigation in case of error. py2exe has a custom .dll loader that bypasses LoadLibrary(Ex) calls from that I can see at http://py2exe.svn.sourceforge.net/viewvc/py2exe/trunk/py2exe/source/ Even if this code can't be used as a replacement for LoadLibrary calls - it can be very useful for troubleshooting problems in case of missing dependencies. It will also help when embedding python or developing extensions. |
|
|
| msg125727 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2011-01-07 23:28 |
| Closing this as "won't fix". Python is not going to reimplement depends.exe. |
|
|
| msg125765 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2011-01-08 08:57 |
| Martin, shouldn't there be at least majority to reach consensus on this matter, or you're self-proclaimed BSDL II? =) At least failed .pyd module name should be present in error message. |
|
|
| msg125768 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2011-01-08 09:30 |
| No idea what a BSDL is, but a developer is definitely entitled to close a bug without resorting to a "majority" decision (what is that, anyway? should we hold monthly parliament over bugs?). You're of course free to reopen with a different request, as you did, and I also think it'd be useful to have the failed module name in the message. |
|
|
| msg126279 - (view) |
Author: Alyssa Coghlan (ncoghlan) * |
Date: 2011-01-14 17:20 |
| As Martin says, we aren't inclined to implement or maintain the equivalent of depends.exe in order to provide a slightly better error message. If anyone wants to reopen this issue, provide a patch. Otherwise devs are just going to close it again. Optionally, campaign for a fix on python-list and see if you can persuade someone *else* to provide a patch. You could even go to the source of the problem and ask *Microsoft* to provide a better error message. |
|
|
| msg126281 - (view) |
Author: Alyssa Coghlan (ncoghlan) * |
Date: 2011-01-14 17:24 |
| Sorry, I missed that the request had changed to just the .pyd name. That at least is useful, since you then know where to start with depends.exe. It should be fairly straightforward to implement as well. Adjusted issue title accordingly. |
|
|
| msg126283 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2011-01-14 17:45 |
| Great. Thanks! |
|
|
| msg141205 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2011-07-27 04:01 |
| How about something like this? ImportError moves from being a "simple" exception to a "complex" one, then adds a "name" and "path" attribute. In dynload_win.c where we try (and fail) to load C extensions, the name and path are set on the ImportError. The test simply creates a file following the C extension name format and checks that the attributes end up being correct upon ImportError. Jazzing up the ImportErrors elsewhere in the code might be useful after this, but I'll handle that in another issue if this gains traction. |
|
|
| msg141209 - (view) |
Author: Alyssa Coghlan (ncoghlan) * |
Date: 2011-07-27 05:53 |
| See also #1559549, which similarly adds attribute support to ImportError and covers some of the issues with using positional arguments to do so. Extending that approach to a path keyword argument as well should work nicely. |
|
|
| msg147439 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2011-11-11 16:30 |
| Marked #1559549 as a dependency. I combine the patch in this issue with the one over there. |
|
|
| msg158399 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2012-04-16 05:10 |
| New changeset f341b99bb370 by Brian Curtin in branch 'default': Fix #10854. Make use of the new path and name attributes on ImportError http://hg.python.org/cpython/rev/f341b99bb370 |
|
|
| msg162376 - (view) |
Author: Kristján Valur Jónsson (kristjan.jonsson) * |
Date: 2012-06-05 22:05 |
| repr() or str() of ImportError doesn't include the 'name' or 'path' members. It would be useful to have them added to the repr if present. |
|
|
| msg162616 - (view) |
Author: Kristján Valur Jónsson (kristjan.jonsson) * |
Date: 2012-06-11 13:18 |
| Brian, reopening this since the original issue isn't addressed: The "path" and "module" attributes aren't part of the error "repr" |
|
|
| msg166124 - (view) |
Author: Kristján Valur Jónsson (kristjan.jonsson) * |
Date: 2012-07-22 11:28 |
| An example patch that aims to put the "name" and "path" in str() and repr() representations of ImportError. Output when _socket.pyd is not found: >>> import socket Traceback (most recent call last): File "", line 1, in File "D:\pydev\hg\cpython3\lib\socket.py", line 47, in import _socket ImportError: No module named '_socket', _socket, >>> sys.last_value <ImportError "No module named '_socket'", '_socket', None> >>> |
|
|
| msg166143 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2012-07-22 15:35 |
| How it the new message better than "ImportError: No module named '_socket'"? |
|
|
| msg166179 - (view) |
Author: Kristján Valur Jónsson (kristjan.jonsson) * |
Date: 2012-07-22 22:53 |
| Ok, the demo demo I added sucks, because I didn't demo the original problem (.pyd found but could not be loaded), but the point is, it displays the "name" and "path" attributes. They can be set, for example, if the module is found but cannot be loaded for some reason. That's the point of this issue. The fix added a "name" and "path" attributes, but they were never actually _output_ when such an error occurred. |
|
|
| msg381184 - (view) |
Author: Irit Katriel (iritkatriel) * |
Date: 2020-11-16 23:31 |
| The patch adding 'name' and 'path' to the ImportError str/repr was not merged yet. |
|
|
| msg381202 - (view) |
Author: Eryk Sun (eryksun) * |
Date: 2020-11-17 01:22 |
| > The patch adding 'name' and 'path' to the ImportError str/repr > was not merged yet. It's up to whatever code raises an ImportError to determine how the name and path should be included in the error message. In Windows, the DLL name was added to the exception message in 3.8. So I'm closing this issue again, with regard to its final scope. With regard to its original scope, the reason for closing is "wont fix". There are no plans to extend the import error of an extension module in Windows to include the missing DLL dependency that caused the import to fail. There are tools such as the "DLL Diagnostics" package on PyPI that implement a proper trace by parsing loader snaps, and at the very least there are tools such as dumpbin.exe (or link.exe /dump) to manually list the direct dependencies of a DLL. |
|
|