Numpy: خطأ في Azure CI (مثيل Windows) مع رقم 1.19.0

هل تفشل باستمرار أم مرة واحدة كل فترة؟ هل لديك أي مطوري Windows يمكنهم محاولة بناء المشروع على جهاز محلي؟

مرحبا،
شكر!

لقد فشلت باستمرار عدة مرات .. في تلك المرحلة فكرت في سؤال مطوري Azure (كان تخميني الأولي أنه ربما تغير شيء ما في إعداد VMs).

يحتوي هذا الرابط على المناقشة التي أجريتها مع أحد مطوري Microsoft الذين اكتشفوا أن المشكلة قد تكون غامضة: https://developercommunity.visualstudio.com/content/problem/1102472/azure-pipeline-error-with-windows-vm.html؟ childToView = 1119179 # تعليق -1119179

لسوء الحظ ، ليس لدي أي شخص يمكنه محاولة بناء المشروع على جهاز windows المحلي :(

ثم سنحتاج إلى مجموعة واضحة من الخطوات لإعادة الإنتاج

هل سيعمل azure-pipelines.yml؟

إليك ما نستخدمه (https://github.com/equinor/pylops/blob/master/azure-pipelines.yml) علق عليه في الوقت الحالي ... يمكنك أن ترى أنه إعداد قياسي جدًا ، باستخدام Python 3.7 ، تثبيت التبعيات في ملف requirements-dev.txt (https://github.com/equinor/pylops/blob/master/requirements-dev.txt) ثم تشغيل الاختبارات.

كما ذكرت سابقًا ، إذا قمت بالتعليق على ذلك وفرضت 1.18.5 على كل شيء ، يبدو أنه 1.19 الجديد لكسر

ما هو إصدار Windows الرئيسي والإصدار الثانوي للصورة التي تعمل على Azure؟ على سبيل المثال ، ما الذي يطبعه systeminfo مقابل OS Version ؟

يمكنني العثور على تفاصيل Azure VMs المستخدمة في Azure Pipelines هنا: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted؟view=azure-devops&tabs=yaml والرابط إلى برنامج مثبت https://github.com/actions/virtual-environment/blob/master/images/win/Windows2019-Readme.md

لست متأكدًا من كيفية تشغيل systeminfo على خط أنابيب Azure ، هل لديك أي اقتراحات؟

يتم تشغيله من سطر الأوامر وتفريغ الإخراج إلى Terminal ، بحيث يمكنك إضافته إلى التشغيل الخاص بك كأمر.

يمكنك القيام بذلك في العلاقات العامة التي تعمل على CI لمعرفة ما تقوله. أسأل نظرًا لوجود مشكلات في الإصدار 19041 من Windows و pip NumPy.

كانت الإجابة في الرابط الثاني:

إصدار نظام التشغيل: 10.0.17763 Build 1282

لذا فإن فكرتي لم تثمر.

أنت تقول إنك تعلم أن هناك بعض المشكلات المتعلقة بأحدث إصدارات نظام التشغيل Windows ، فهل من المحتمل أن تكون مرتبطة بذلك؟

إنه في الواقع (على الأرجح) خطأ في Windows تم تقديمه في عام 19041. لكنك تستخدم إصدارًا أقدم بكثير ، لذا فهذه ليست المشكلة.

لا يؤثر ذلك على Conda NumPy ، فقط ضع علامة على NumPy لأنه يبدو أن هناك بعض المشكلات مع Windows و OpenBlas.

أرى :) تلقيت رسالة بريد إلكتروني تفيد بإصدار 1.9.1. سأحاول إعادة إنشاء خط أنابيب Azure الذي سيثبت الآن أحدث إصدار ومعرفة ما إذا كان ذلك يعمل ، سيعلمك

للأسف ما زال يفشل مع 1.19.1 https://dev.azure.com/matteoravasi/PyLops/_build/results؟buildId=45&view=logs&j=50448a2f-9550-51a0-b6c4-5ec64224dd81&t=a6a6804f-7af1-5f53-fb6778 :(

خطأ في OpenBlas.

هنا مثال استنساخ:

import numpy as np
nr = 12000
v = np.random.randn(nr) + 1j * np.random.randn(nr)
np.vdot(v, v)
# also access violations
v @ v
# also access violations

معلومات تصحيح أخطاء "لا" هي:

Exception thrown at 0x0000000068DBB8F0 (libopenblas.NOIJJG62EMASZI6NYURL6JBKM4EVBGM7.gfortran-win_amd64.dll)
in python.exe: 0xC0000005: Access violation reading location 0x0000000000000000.

لاحظ أن المصفوفة يجب أن تكون كبيرة جدًا (10 كيلو بايت ، 12 كيلو بايت لا) لتشغيل الخطأ.

فحص سريع:

$env:OPENBLAS_VERBOSE=2
$env:OPENBLAS_CORETYPE=Prescott

يمر لكن النواة الافتراضية ( Zen ) ، بالإضافة إلى Haswell و Sandybridge ، كلاهما لهما انتهاكات في الوصول.

ربما يكون من المفيد التحقق من فشل هذا HEAD الخشن ، والذي يستخدم أحدث OpenBLAS 0.3.10. أو ربما فعلت بالفعل؟

mattip لا لم أحاول هذا بعد. تقصد تثبيت وعرة مباشرة من السيد مع pip install git+https://github.com/numpy/numpy ؟ يمكنني أن أجربها :)

وعلى سؤالك bashtage (هل تستخدم الاختبارات الفاشلة numba على الإطلاق؟ يحتوي numba 0.50 على خطأ في بعض إصدارات Windows حيث يستخدم بشكل غير صحيح عنصرًا جوهريًا غير متوفر. وقد تسبب هذا في تعطل لي في مشروع آخر.) البريد الإلكتروني ولكن لا يبدو أنه يمكن رؤيته في سلسلة الرسائل هذه ... يستخدم الاختبار الذي يتعطل عمليتي numpy و pyfftw . نظرًا لأنه يتعطل مع هذه الرسالة المفاجئة ، يصعب تحديد الخط الذي يتعطل فيه حقًا. لكني لا أعتقد أن pyfftw يستخدم numba على الإطلاق ، على الأقل ليس أحد تبعياتهم

لقد جربت للتو تثبيت HEAD of NumPy مباشرة من مستودع GitHub ويعمل بناء windows حتى الاكتمال - لا يوجد عطل مفاجئ: https://dev.azure.com/matteoravasi/PyLops/_build/results؟buildId=54&view=logs&j= 011e1ec8-6569-5e69-4f06-baf193d1351e & t = bf6cf4cf-6432-59cf-d384-6b3bcf32ede2

من المثير للاهتمام أن بعض المكتبات التي تحتوي على NumPy كتبعية لا يبدو أنها مثبتة بشكل صحيح (لست متأكدًا من السبب) وتفشل بعض الاختبارات لجميع أنظمة التشغيل ، ولكنها على الأقل ليست تعطلًا كاملاً كما كان من قبل ...

لا خطأ في استخدام ليلا:

pip install -i https://pypi.anaconda.org/scipy-wheels-nightly/simple numpy

لقد حاولت للتو تثبيت HEAD of NumPy مباشرة من مستودع GitHub

هذا لا يحتوي على OpenBLAS إلا إذا قمت ببنائه بشكل صريح. بشكل افتراضي ، تحصل على BLAS بطيء عام مع pip install git+https://github.com/numpy/numpy.git .

يبدو أننا قد نرغب في ترقية OpenBLAS للإصدار 1.19.2 ، لذا يجب وضع علامة على هذا.

أعتقد أنني قد أواجه نفس المشكلة في أحدث إصدار --pre (numpy-1.20.0.dev0 + a0028bc) على Azure :

Current thread 0x000003d0 (most recent call first):
  File "<__array_function__ internals>", line 5 in dot
  File "D:\a\1\s\mne\minimum_norm\inverse.py", line 732 in _assemble_kernel

السطر المعني هو فقط:

K = np.dot(eigen_leads, trans)

إذا كان ذلك مفيدًا ، فيمكنني محاولة حفظ المصفوفات على القرص وإخراجها عبر أداة Azure.

يبدو ذلك. أنت تستخدم نفس الإصدار السابق الذي كنت أعمل به بشكل صحيح.

قد ترغب في إضافة

$env:OPENBLAS_VERBOSE=2

أو

set OPENBLAS_VERBOSE=2

إلى القالب الخاص بك لمعرفة النواة المستخدمة.

إذا كان ذلك مفيدًا ، فيمكنني محاولة حفظ المصفوفات على القرص وإخراجها عبر أداة Azure.

ربما يكون كافياً لمعرفة الأنواع والأبعاد.

حسنًا ، تمت إعادة إنتاجه في جولة واحدة من الاختبار الفاشل فقط باستخدام numpy + scipy + matplotlib + pytest (و deps) الذي يكتب المصفوفات التي يتم ضربها ثم تحميلها ، وهنا علامة تبويب القطع الأثرية:

https://dev.azure.com/mne-tools/mne-python/_build/results؟buildId=8330&view=artifacts&type=publishedArtifacts

يجب أن يكون آخر .npz هو الفاشل (27 ميغابايت). محليًا على نظام Linux ، النقاط جيدة:

>>> import numpy as np
>>> data = np.load('1595525222.9485037.npz')
>>> np.dot(data['a'], data['b']).shape
(23784, 305)
>>> data['a'].shape, data['a'].dtype, data['b'].shape, data['b'].dtype
((23784, 305), dtype('>f4'), (305, 305), dtype('float64'))
>>> data['a'].flags, data['b'].flags
(  C_CONTIGUOUS : False
  F_CONTIGUOUS : True
  OWNDATA : False
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False
  UPDATEIFCOPY : False
,   C_CONTIGUOUS : True
  F_CONTIGUOUS : False
  OWNDATA : True
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False
  UPDATEIFCOPY : False
)

العمل على تشغيل OPENBLAS_VERBOSE ولكن يبدو أنه في كل مرة أستخدم فيها pytest -s لعدم التقاط الناتج الذي يمر به بالفعل. قد يكون هذا مجرد مصادفة ، رغم ذلك ، سنرى ...

مضحك ، أراه أيضًا مع الناسخ أعلاه الآن.

لا أرى ذلك إذا قمت بتعيين OPENBLAS_CORETYPE على Prescott أو Nehalem. أراه مع Zen و Sandybridge و Haswell.

لا يمكنني إعادة الإنتاج محليًا باستخدام البيانات من npz على Windows.

لا يمكنني إعادة الإنتاج محليًا باستخدام البيانات من npz على Windows.

FWIW على Azure يمكنني إعادة إنتاجه باستخدام بيانات الحفظ - التحميل - الجولة - التعثر ، لأنه فشل الآن في السطر الثاني إلى الأخير في التعليمات البرمجية المنفذة هنا:

    import mne, os.path as op, time
    fname = op.join(op.dirname(mne.__file__), '..', 'bad', f'{time.time()}.npz')
    np.savez_compressed(fname, a=eigen_leads, b=trans)
    print(eigen_leads.flags)
    print(trans.flags)
    data = np.load(fname)
    np.dot(data['a'], data['b'])  # <-- fails here
    K = np.dot(eigen_leads, trans)   # <-- used to fail here before I added the above lines

لذلك لا يتم فقد أي شيء على الأقل في نهاية Azure بسبب الخطوات np.savez / np.load .

أحاول الجري باستخدام OPENBLAS_CORETYPE: 'nehalem' لمعرفة ما إذا كان ذلك مفيدًا.

لذلك ربما يوجد في الواقع خطأان مختلفان هنا؟

أيضًا ، لا يبدو أن تعيين OPENBLAS_VERBOSE: 2 له أي تأثير ، ولست متأكدًا من السبب

بعد الضبط المطول ، أضف أمرًا

python -c "استيراد numpy"

ربما يأكل Pytest هذا على ما أعتقد.

في الخميس ، 23 يوليو 2020 ، الساعة 19:04 ، كتب إريك لارسون [email protected] :

أيضًا ، لا يبدو أن إعداد OPENBLAS_VERBOSE: 2 له أي تأثير ، لا
متأكد من السبب

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/numpy/numpy/issues/16913#issuecomment-663151960 ، أو
إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/ABKTSRNS5QRT6CC3ZQ6DQYDR5B3TTANCNFSM4PCRVE6A
.

هذا الأمر محليًا لا يعطيني أي إخراج مطول:

OPENBLAS_VERBOSE=2 python -c "import numpy as np, glob; data = np.load(glob.glob('bad/*.npz')[0]); a, b = data['a'], data['b']; print(np.dot(a, b).shape)"

لكن ربما نظام OpenBLAS الخاص بي قديم جدًا. سأقوم بدفع الالتزام بـ Azure لجعله يقوم بتشغيل هذا بنفسه بعد فشله.

يبدو أن كلمة OPENBLAS_VERBOSE على Azure تقول "Core: Haswell". لا أعرف ما إذا كان هذا صحيحًا أم لا.

لقد أبلغت عن الخطأ في https://github.com/xianyi/OpenBLAS/issues/2732 واقترحوا أنه قد يتم إصلاحه بشكل رئيسي ، راجع https://github.com/xianyi/OpenBLAS/issues/2728 . لا توجد فكرة عن أفضل طريقة لاختبار ذلك.

mattip هل نعلم أن هذا مغلق بواسطة MacPython / openblas-libs # 35؟ ألا نحتاج إلى الانتظار حتى انتهاء الأسبوع القادم؟

charris أعتقد أن هذه المشكلة لا تزال مفتوحة ومن المحتمل أن تكون هناك حاجة إلى

هل يمكن لشخص ما لديه ناسخ أن يحاول بناء numpy بهذا الالتزام للحصول على أحدث ثنائيات OpenBLAS؟ شيء مثل (mabe مع الأخطاء المطبعية)

git add remote mattip https://github.com/mattip/numpy.git
git fetch mattip  issue-16913
git checkout issue-16913
python tools/openblas_support.py
# copy the output openblas.a to a local directory and make sure numpy uses it
mkdir openblas
copy /path/to/openblas.a openblas
set OPENBLAS=openblas
python -c "from tools import openblas_support; openblas_support.make_init('numpy')"
pip install --no-build-isolation --no-use-pep517 .

يجب تثبيت gfortran بـ choco install -y mingw إذا لم تكن قد قمت بذلك بالفعل

... هذا من أجل windows

يجب أن يكون لديك تثبيت gfortran مع choco install -y mingw إذا لم تكن قد قمت بذلك بالفعل

هل هذا مطلوب فقط لـ 32 بت؟

https://github.com/numpy/numpy/blob/master/azure-steps-windows.yml#L29 -L31

سأحاول ما تقترحه أعلاه بـ choco install -y mingw بمجرد أن أكتشف ما هو /path/to/openblas.a - على الأرجح من تشغيل tools/openblas_support.py (؟).

نعم ، يطبع python tools/openblas_support.py مكان العثور على openblas.a

أنت بحاجة إلى gfortran. تم تثبيت mingw 64 بت على الأجهزة اللازوردية. إذا كنت 32 بتًا ، فإن الاستدعاء مختلف قليلاً. تحتاج أيضًا إلى تعيين -m32 (ولكن 32 بت فقط).

لقد نسخت حرفياً معظم https://github.com/numpy/numpy/blob/master/azure-steps-windows.yml باستخدام master فرع NumPy لإعادة إنتاج الخطأ أولاً ، ونجحت في الحصول على انها segfault .

ثم قمت بالتبديل إلى mattip/issue-16913 وفشل الأمر مع ظهور خطأ في تنزيل عنوان URL لـ:

https://anaconda.org/multibuild-wheels-staging/openblas-libs/v0.3.9-452-g349b722d/download/openblas-v0.3.9-452-g349b722d-win_amd64-gcc_7_1_0.zip

... يبدو أنه لا يوجد OpenBLAS 32 بت لنظام التشغيل Windows 64 بت في:

https://anaconda.org/multibuild-wheels-staging/openblas-libs/files

أعتقد أنه يمكنني إضافة العلامة للحصول عليها لاستخدام OpenBLAS 64 بت؟

2 هناك و 1 لا يزال قيد البناء. يجب أن يصل في غضون ساعة.

في غضون ذلك أضفت:

        NPY_USE_BLAS_ILP64: '1'
        OPENBLAS_SUFFIX: '64_'

وبنيت على ما يرام. لم تعد segfaults ! سأعيد تشغيله عدة مرات فقط للتأكد. لا تتردد في إرسال اختبار الاتصال لي عند تشغيل حزم OpenBLAS Win64 ذات الإصدار 32 بت ويمكنني بسهولة إزالة هذه الخطوط وإعادة الاختبار.

أي تغيير تقوم بتشغيل مجموعة الاختبار الكاملة :-)

python -c "import numpy; numpy.test('full')"

يبدو أن الآحاد ذات 32 بت تعمل ، وهذا يعمل أيضًا .

سأقوم بتشغيل مجموعة الاختبار الكاملة الآن

يظهر خطأ غريب في مجموعة الاختبار يتضمن f2py :

https://dev.azure.com/mne-tools/mne-python/_build/results؟buildId=8372&view=logs&j=a846d25a-e32c-5640-1b53-e815fab94407&t=14a4ea33-5055-5caa-db84-413553e060

يجب ألا تضيع المزيد من الوقت في هذه المشكلة الأخرى - يمكنني الانتظار حتى الأسبوع المقبل واختبار الأسبوعية التي نأمل أن تحتوي على BLAS.

لاحظ أنه يمكننا تشغيل الإصدارات الليلية في أي وقت عن طريق دفع الالتزام إلى الفرع الرئيسي.

حسنًا ، سأنتظر حتى أرى واحدة جديدة لمعرفة ما إذا تم إصلاح مشكلة Windows 10 2004.

bashtage أي تحديث على هذا؟

لا يزال OpenBLAS معطلاً في أحدث إصدار من Windows. إنه أمر غير قياسي للغاية حتى الحصول على معلومات تصحيح أخطاء جيدة بسبب سلسلة مختلطة إلى أداة ، على الأقل بالنسبة لي.