Numpy: Numpy 1.10.2 + MKL = crash (Windows)

Hmm, je ne sais pas ce qui se passe ici. Intel a apporté quelques modifications à la version, mais je ne pense pas que cela soit impliqué. Python 3.5 est un coupable possible car il est compilé avec un VS plus récent sur Windows. Pensées @cgohlke ?

Je pense que votre meilleur pari est de fournir un reproducteur (quelles sont les "certaines fonctions" qui produisent cela?), Et soit d'espérer que @cgohlke apparaîtra avec la réponse ou bien de déposer un bogue avec Anaconda (car ils ont les ressources pour prendre en charge leur MKL construit et nous ne le faisons pas).

Désolé pour les "quelques fonctions" :) - il s'est écrasé indirectement via matplotlib.

Cela plante tout de même:

A = np.arange(2*3).reshape(2,3).astype(np.float32)
B = np.arange(2*3*2731).reshape(2,3,2731).astype(np.int16)

np.dot(A, B)

J'ai fait une vérification rapide avec le dernier @cgohlke numpy (1.10.2) python-3.4 (64bit) ainsi que python-3.5 (64bit) sur mon ordinateur portable:

>>> np.show_config()
openblas_lapack_info:
  NOT AVAILABLE
lapack_mkl_info:
    include_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/include']
    libraries = ['mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt', 'mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt']
    library_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
lapack_opt_info:
    include_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/include']
    libraries = ['mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt', 'mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt']
    library_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
mkl_info:
    include_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/include']
    libraries = ['mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt']
    library_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
blas_mkl_info:
    include_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/include']
    libraries = ['mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt']
    library_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
blas_opt_info:
    include_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/include']
    libraries = ['mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt']
    library_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]

>>> import numpy as np
>>> A = np.arange(2*3).reshape(2,3).astype(np.float32)
>>> B = np.arange(2*3*2731).reshape(2,3,2731).astype(np.int16)
>>> np.dot(A, B)
array([[[  13655.,   13658.,   13661., ...,   21839.,   21842.,   21845.],
        [  38234.,   38237.,   38240., ...,   46418.,   46421.,   46424.]],

       [[  38234.,   38246.,   38258., ...,   70970.,   70982.,   70994.],
        [ 136550.,  136562.,  136574., ...,  169286.,  169298.,  169310.]]], dtype=float32)

Les deux fonctionnent comme prévu pour moi.

Je suppose que l'erreur Intel MKL FATAL ERROR: Cannot load mkl_intel_thread.dll pourrait être expliquée en raison d'une mauvaise version de mkl_intel_thread.dll trouvée quelque part sur PATH . La localisation des DLL MKL en étendant le PATH comme cela est fait dans numpy + MKL est fragile si un autre runtime MKL est installé sur le système.

Y a-t-il des fichiers libiomp5md.dll ou mkl_*.dll dans les répertoires C: \ Windows *?

@cgohlke , dans numpy + MKL vous avez introduit _init_numpy_mkl() pour ajouter numpy.core au PATH .

Avez-vous envisagé l'approche suivante de https://gist.github.com/matham/f6a07f8fb5e403feb440 pour modifier l'ordre de recherche des DLL?

Voir également:
https://pytools.codeplex.com/workitem/1627 (d'où il vient)
https://github.com/numpy/numpy/wiki/windows-dll-notes#python -dlls
http://stackoverflow.com/questions/23804438/find-library-in-ctypes

@cgohlke Voici les DLL trouvées dans mon répertoire Windows:

['System32\\libiomp5md.dll',
 'System32\\mkl_core.dll',
 'System32\\mkl_def.dll',
 'System32\\mkl_intel_thread.dll',
 'SysWOW64\\libiomp5md.dll',
 'SysWOW64\\mkl_core.dll',
 'SysWOW64\\mkl_intel_thread.dll',
 'SysWOW64\\mkl_p4.dll',
 'SysWOW64\\mkl_p4m.dll',
 'SysWOW64\\mkl_p4m3.dll',
 'SysWOW64\\mkl_p4p.dll']

Essayer de réinitialiser mon PATH avec SET PATH=; avant d'appeler python plante toujours, mais la suppression complète des DLL ci-dessus du répertoire Windows arrête le crash. Cela ressemble à un problème de priorité de chemin @carlkl.

@cgohlke , je propose le changement suivant pour tester avec numpy + MKL's __init__.py

def _init_numpy_mkl():
    # Numpy+MKL on Windows only
    import os
    import ctypes
    if os.name != 'nt':
        return
    # disable Intel Fortran default console event handler
    env = 'FOR_DISABLE_CONSOLE_CTRL_HANDLER'
    if env not in os.environ:
        os.environ[env] = '1'
    # extend DLL search order with numpy.core
    # See https://github.com/numpy/numpy/wiki/windows-dll-notes#python-dlls
    # and https://pytools.codeplex.com/workitem/1627
    try:
        _AddDllDirectory = ctypes.windll.kernel32.AddDllDirectory
        _AddDllDirectory.argtypes = [ctypes.c_wchar_p]
        # Needed to initialize AddDllDirectory modifications
        ctypes.windll.kernel32.SetDefaultDllDirectories(0x1000)
    except AttributeError:
        _AddDllDirectory = ctypes.windll.kernel32.SetDllDirectoryW
        _AddDllDirectory.argtypes = [ctypes.c_wchar_p]
    try:
        _core = os.path.join(os.path.abspath(os.path.dirname(__file__)), 'core')
        _AddDllDirectory(_core)
    except Exception:
        pass

_init_numpy_mkl()
del _init_numpy_mkl

la suppression complète des DLL ci-dessus du répertoire Windows arrête le crash.

Bon débarras.

Je propose le changement suivant pour tester avec numpy + MKL's __init__.py

Cela ne fonctionnera pas vraiment sur les systèmes plus anciens et, plus important encore, cela casse les packages qui dépendent de l' ordre de recherche des DLL du système. Cela peut être acceptable pour des distributions comme Anaconda ou WinPython.

Je trouve amusant d'avoir initialement trouvé la méthode AddDllDirectory dans le wiki numpy qui a été partiellement créditée à @carlkl , mais mon utilisation a été proposée ici par @carlkl à titre d'exemple, et je me suis retrouvé ici parce que d'un problème avec cet exemple de code lors de la recherche de numpy pour AddDllDirectory . C'est la boucle ...

Quoi qu'il en soit, je voulais noter pour les autres qui envisagent d'utiliser ceci, que la ligne ctypes.windll.kernel32.SetDefaultDllDirectories(0x1000) (et tout autre indicateur nul-zéro) provoque des exceptions ImportError: DLL load failed: The parameter is incorrect lors du chargement de certaines dll. Pour moi, cela ne s'est produit que spécifiquement avec une extension construite mingw-w64 (mingwpy) liée aux dll ffmpeg qui ont été compilées de manière croisée sur debian avec mingw-w64. Mais je ne sais pas si c'était responsable.

Cependant, parce que python appelle LoadLibraryEx uniquement avec LOAD_WITH_ALTERED_SEARCH_PATH et non avec LOAD_LIBRARY_SEARCH_USER_DIRS , à moins que SetDefaultDllDirectories soit également appelé avec LOAD_LIBRARY_SEARCH_USER_DIRS , LoadLibraryEx ne recherchera pas les répertoires ajoutés avec AddDllDirectory . Pour moi, cela semble un peu trop fragile à utiliser, donc je pense que je vais revenir à l'ajout du répertoire dll au chemin avec os.environ . Je me demande si je devrais mettre à jour le wiki avec ces informations, cependant?

Quoi qu'il en soit, j'espère que ce n'était pas trop loin du sujet.

@matham , cet extrait de code doit être crédité à _zooba_ - voir https://pytools.codeplex.com/workitem/1627. La ligne ctypes.windll.kernel32.SetDefaultDllDirectories(0x1000) ne change pas le comportement de LoadLibraryEx avec LOAD_WITH_ALTERED_SEARCH_PATH . J'espère que cela change le comportement de LoadLibraryA (_without_ LOAD_WITH_ALTERED_SEARCH_PATH ) qu'il utilisait pour charger MKL_INTEL_THREAD.DLL juste après le chargement aléatoire de \ mtrand.pyd et MKL_RT.DLL puis appels MKL_INTEL_THREAD.DLL :

log du marcheur de la dépendance pendant python -c "import numpy"

...
LoadLibraryExW("d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\random\mtrand.cp35-win_amd64.pyd", 0x0000000000000000, LOAD_WITH_ALTERED_SEARCH_PATH) called from "d:\devel\py\python-3.5.0.amd64\PYTHON35.DLL" at address 0x00000000587E7747.
Loaded "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\random\MTRAND.CP35-WIN_AMD64.PYD" at address 0x000007FEF3310000.  Successfully hooked module.
DllMain(0x000007FEF3310000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\random\MTRAND.CP35-WIN_AMD64.PYD" called.
DllMain(0x000007FEF3310000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\random\MTRAND.CP35-WIN_AMD64.PYD" returned 1 (0x1).
LoadLibraryExW("d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\random\mtrand.cp35-win_amd64.pyd", 0x0000000000000000, LOAD_WITH_ALTERED_SEARCH_PATH) returned 0x000007FEF3310000.
LoadLibraryA("d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\core\mkl_intel_thread.dll") called from "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\core\MKL_RT.DLL" at address 0x000007FEE17C4772.
Loaded "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\core\MKL_INTEL_THREAD.DLL" at address 0x000007FEE0520000.  Successfully hooked module.
Loaded "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\core\MKL_CORE.DLL" at address 0x000007FEDEEC0000.  Successfully hooked module.
Loaded "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\core\LIBIOMP5MD.DLL" at address 0x000007FEE43E0000.  Successfully hooked module.
...

@carlkl true, mais je faisais référence au wiki: (thanks to Steve Dower for the fragment, Carl Kleffner for finding it) , que j'ai supposé être vous :)

La fragilité à laquelle je faisais référence est qu'en général, il peut y avoir un autre code exécuté entre l'appel SetDefaultDllDirectories qui définit cet indicateur et le moment où la bibliothèque est réellement chargée. Par exemple, si vous importez quelque chose qui lui-même appelle SetDefaultDllDirectories peut-être avec une valeur (par exemple 0), ce qui peut entraîner la disparition de la DLL ultérieurement lors de l'importation. Bien que je suppose que cela ne pose pas de problème ici s'il est immédiatement importé.

@cgohlke , y a-t-il quelque chose de mal avec le préchargement de MKL_RT.DLL , MKL_INTEL_THREAD.DLL et MKL_CORE.DLL avec un chemin explicite vers numpy.core dans _init_numpy_mkl() ? Je ne suis pas sûr que le chargement progressif d'autres DLL MKL nécessaires fonctionne alors.

@cgohlke ,

L'extrait suivant garantit (?) que les DLL MKL sont chargées à partir de numpy.core et non à partir d'un système Windows ou d'un dossier de redistribution Intel. L'ordre de chargement des DLL est important. Au moins, cela fonctionne pour Windows 7 python-3.4 bit.

def _init_numpy_mkl():
    # Numpy+MKL on Windows only
    import os
    import ctypes
    if os.name != 'nt':
        return
    # disable Intel Fortran default console event handler
    env = 'FOR_DISABLE_CONSOLE_CTRL_HANDLER'
    if env not in os.environ:
        os.environ[env] = '1'
    # preload MKL DLLs from numpy.core
    try:
        _core = os.path.join(os.path.abspath(os.path.dirname(__file__)), 'core')
        for _dll in ('mkl_rt', 'libiomp5md', 'mkl_core', 'mkl_intel_thread', 
                     'libmmd', 'libifcoremd', 'libimalloc'):
            ctypes.cdll.LoadLibrary(os.path.join(_core,_dll))
    except Exception:
        pass

_init_numpy_mkl()
del _init_numpy_mkl

J'ai eu le même problème et je l'ai retracé pour installer mkl_intel_thread.dll dans C:\Windows\System32 comme indiqué par danielgeier.
L'ancienne version n'avait pas entre autres le mkl_aa_fw_get_max_memory .
Le moment de la création a coïncidé avec l'installation des pilotes audio Asio4all. Après avoir désinstallé ceux-ci, qui ont supprimé plusieurs dll, cela a fonctionné à nouveau (mieux que de simplement supprimer les dll dans system32 par moi-même).
J'ai joué avec la restauration et la mise à jour de la distribution anaconda, mais cela n'a pas fonctionné. Je ne pouvais pas non plus désactiver mkl avec anaconda sur Windows.

@ sebastian-schmidt, pouvez-vous essayer, si le chargement explicite des DLL MKL à partir du dossier numpy / core fonctionne pour vous, même avec des DLL MKL obsolètes installées dans le dossier système Windows. Voir ci-dessus: https://github.com/numpy/numpy/issues/6923#issuecomment -169073613

@carlkl , où dois-je ajouter l'extrait de code?
J'ai essayé de l'ajouter au fichier que j'ai utilisé comme test: https://gist.github.com/sebastian-schmidt/9bb97354b481750209fd3dac1e748d31 et cela n'a pas fonctionné.
Le chemin joint est juste un sous-répertoire à partir duquel j'appelle le fichier.
Dois-je l'ajouter à l'init du module Numpy?

La fonction _init_numpy_mkl() fait partie des roues @cgohlke numpy + mkl. Vous pouvez le trouver dans le fichier __init__.py . Il ne fait pas partie des sources numpy officielles.

Voici la version trouvée dans numpy-1.10.4+mkl-cp34-none-win32.whl

def _init_numpy_mkl():
    # Numpy+MKL on Windows only
    import os
    if os.name != 'nt':
        return
    # disable Intel Fortran default console event handler
    env = 'FOR_DISABLE_CONSOLE_CTRL_HANDLER'
    if env not in os.environ:
        os.environ[env] = '1'
    # prepend the path of the Intel runtime DLLs to os.environ['PATH']
    try:
        path = os.path.join(os.path.abspath(os.path.dirname(__file__)), 'core')
        if path not in os.environ.get('PATH', ''):
            os.environ['PATH'] = os.pathsep.join((path, os.environ.get('PATH', '')))
    except Exception:
        pass

_init_numpy_mkl()
del _init_numpy_mkl

Cette fonction ajoute la numpy/core dossier à PATH environnement. Cependant, les DLL trouvées dans le dossier système Windows sont préférées aux DLL trouvées dans le PATH. Bienvenue dans l'enfer des DLL.

La version alternative de cette fonction https://github.com/numpy/numpy/issues/6923#issuecomment -169073613 charge les DLL MKL à partir de numpy/core dans le bon ordre _sans_ changer l'environnement PATH . Tous les noms de DLL sont donnés sous forme de noms de fichiers explicites avec un chemin d'accès complet, donc je ne m'attends pas à des problèmes avec les DLL d'observation dans le dossier système Windows, mais je ne l'ai pas testé.

Cependant, je me fichais de la numpy gelée dans cet extrait de code.

J'ai changé le _init_numpy_mkl() dans la distribution Anaconda à votre version, puis cela a fonctionné (avec des dll incompatibles dans windows/system32 .

Ravi de l'entendre!

Le code _init_numpy_mkl () fait partie de la distribution numpy d » @cgohlke et sous son responibility.
@cgohlke : des commentaires sur https://github.com/numpy/numpy/issues/6923#issuecomment -169073613?

@ sebastian-schmidt, pouvez-vous tester la version en utilisant AddDllDirectory (ou SetDllDirectoryW comme solution de secours): voir ci-dessus: https://github.com/numpy/numpy/issues/6923#issuecomment -168490201

@carlkl , la version AddDllDirectory / SetDllDirectoryW fonctionne également.
Le test était toujours uniquement l'exemple np.dot() de danielgeier.
Par ailleurs, le logiciel qui installe les bibliothèques mkl était Amplitube et non les pilotes Asio4all.

Moi aussi, j'ai retracé le problème à Amplitube.

quand j'ai essayé: import matplotlib.pyplot as plt avec les deux versions init, j'ai eu une erreur:

---> 60 import matplotlib._png as _png
     61 ####################
     62 

ImportError: DLL load failed: Das angegebene Modul wurde nicht gefunden.

Je suis donc revenu à la version originale d'Anaconda et j'ai laissé Amplitube désinstallé.

@ sebastian-schmidt, au moins ça marche pour moi. L'importation de numpy, scipy, matplotlib._png fonctionne sans problème sur ma box.

Cependant, la désinstallation des DLL MKL des dossiers système Windows semble être la meilleure solution pour ce genre de problèmes.

Il est temps de fermer ce problème?

Salut les gars. Juste au cas où quelqu'un aurait encore ce problème. J'ai numpy 1.12 + mkl et j'ai eu le même problème. J'ai désinstallé Amplitube 3 et maintenant tout fonctionne!

Salut les gars,

Je viens d'installer le dernier package numpy + mkl 1.13 d' ici par @cgohlke .

J'utilise Anaconda avec Python 3.6.1 64 bits sur Windows 7.

Après cela, j'obtiens également ce problème de DLL, cela fonctionnait bien pour la version 1.12 du même site auparavant.

Pour ajouter, en fait tout le code fonctionne dans un notebook Jupyter .... Cela ne se produit que dans une console.

@carlkl J'ai cherché dans mon dossier Anaconda pour _init_numpy_mkl mais je n'ai pas pu trouver le fichier contenant cette chaîne. L'ajout manuel de numpy/core à ma variable PATH env ne fonctionnait pas non plus.

D'autres suggestions?

Merci.

quand j'ai importé skimage, j'ai rencontré le problème "impossible de charger le mkl_intel_thread.dll".
Je ne trouve aucun mkl_intel_thread.dll dans windows / system32, donc j'ai supprimé le libiomp5md.dll dans ce dossier comme @cgohlke l'a mentionné, cela fonctionne！ merci beaucoup! le problème m'a troublé des semaines. Quoi qu'il en soit, j'espère que les autres ont rencontré ce problème peuvent obtenir de l'aide. Essayez de trouver libiomp5md.dll, cela peut aider.

Je me demande si https://github.com/numpy/numpy/issues/6923#issuecomment -169073613 fonctionne dans ce cas sans qu'il soit nécessaire de supprimer les DLL MKL de windows / system32. Cet extrait de code montre qu'il est possible de charger sept DLL MKL (mais pas toutes) dans le dossier numpy / core sans avoir besoin de transmettre des bibliothèques supplémentaires à la variable d'environnement PATH ou d'utiliser d'autres astuces. Il est important de charger ces 7 DLL dans le bon ordre. Toutes les autres DLL MKL requises sont ensuite automatiquement chargées à partir de numpy / core au lieu du dossier windows / system32.

On ne sait pas encore si cela fonctionne dans tous les scénarios imaginables. Par exemple, les applications python gelées. Les versions du système d'exploitation Windows peuvent également différer dans le comportement de chargement de la DLL.

Il me semble avantageux d'approfondir cette variante.

Nous avons fait des allers-retours avec SetDefaultDllDirectories , # 10229 l'a ajouté puis # 11493 l'a supprimé. Je pense que nous sommes allés aussi loin que possible avec cela. Il semble que la meilleure option soit de supprimer les autres copies de mkl de PATH.

Veuillez rouvrir si vous n'êtes pas d'accord.