Lapack: Segfault في ./EIG/xeigtstz

تم إنشاؤها على ١٩ أبريل ٢٠١٩ · 11تعليقات · مصدر: Reference-LAPACK/lapack

أهلا،

هذا مع Lapack 3.8.0.

يحدث Segfault في xeigtstz مع lapack 3.8.0 و gfortran الأخير:

./EIG/xeigtstz <nep.in> znep.out 2> & 1
/ bin / sh: Zeile 1: 9026 Speicherzugriffsfehler (Speicherabzug geschrieben) ./EIG/xeigtstz <nep.in> znep.out 2> & 1

يختفي هذا عندما يتم رفع حد المكدس من الافتراضي 8192 كيلو بايت إلى 81920 كيلو بايت (ملف
أول قيمة حاولت).

Build System Testing

مصدر

Dichloromethane

ال 11 كومينتر

يبدو أنه نسخة مكررة من https://github.com/Reference-LAPACK/lapack/issues/276 .

Dichloromethane في ١٩ أبريل ٢٠١٩

👍1

يشير gfortran9 إلى وصول خارج الحدود في (من بين أمور أخرى) TESTING / EIG / zhet21.f السطر 304 (تنفيذ حلقة على J تعمل من 1 إلى N-1 ، والوصول إلى عنصر المصفوفة U (1 ، J-1 ) ... أوتش). لست متأكدًا مما إذا كان هذا هو السبب الفعلي والوحيد لهذه المشكلة حتى الآن ...
تحرير: ملاحظتي ليست ذات صلة (وقد فاتني بالفعل أنك فتحت بالفعل رقم 333 لها) يحاول xeigtstz تخصيص حوالي 10 ميجابايت على المكدس لاختبارات NEP كما هو مذكور بالفعل في https://github.com/xianyi/OpenBLAS/ القضايا / 1645

martin-frbg في ١٩ أبريل ٢٠١٩

تعيين ulimit -s 16384 بدلاً من 8192 الافتراضي أدى إلى إصلاح هذه المشكلة بالنسبة لي أيضًا

pdabacus في ٢٣ يونيو ٢٠٢٠

👍1

نفس المشكلة هنا # 85.

weslleyspereira في ١٧ فبراير ٢٠٢١

كان حل go-to لهذه المشكلة هو زيادة حد المكدس ولكن نظرًا لأن هذا اختبار ، فهل لن يكون تخصيص الكومة حلاً أفضل؟

christoph-conrads في ١٧ فبراير ٢٠٢١

👍1

أعتقد أن المصفوفات القابلة للتخصيص تنتهي في المكدس بسبب الخيار "العودي" (مطلوب لسلامة الخيط) لكنني لم أتمكن بعد من العثور على حل عملي.

martin-frbg في ١٧ فبراير ٢٠٢١

سيحاول weslleyspereira ترجمة zchkee.f فقط بدون الخيار -frecursive. لذلك سيتم تجميع جميع الملفات (على وجه الخصوص liblapack.a) باستخدام الخيار -frecursive ، ولكن سيتم تجميع zchkee.f بدون الخيار -frecursive. نعتقد / نأمل أن تفي بالغرض. سنختبر. أعتقد أنه من المهم تجميع LAPACK باستخدام -frecursive. الآن يمكن تجميع zchkee.f بدون. سيكون ذلك على ما يرام. سيبدو صنع وصنع أكثر بشاعة. أعتقد أننا طال انتظارنا لمجموعة اختبار جديدة ، لذلك نقترح أن نقوم بذلك بشكل قبيح في الوقت الحالي ، والتركيز على مجموعة اختبار جديدة.

langou في ١٧ فبراير ٢٠٢١

عملت من أجلي طالما أنني لم أستخدم OpenMP أيضًا ، لكن هذا الأخير يشير للأسف - متكرر
(يمكن استخدام filter_out في Makefile لتجريد frecursive / Mrecursive من FFLAGS ، لذا لا يوجد الكثير من القبح الجديد)

martin-frbg في ١٧ فبراير ٢٠٢١

عملت من أجلي طالما أنني لم أستخدم OpenMP أيضًا ، لكن هذا الأخير يشير للأسف - متكرر

آه. نعم ، هذه مشكلة محتملة.

(يمكن استخدام filter_out في Makefile لتجريد frecursive / Mrecursive من FFLAGS ، لذا لا يوجد الكثير من القبح الجديد)

آه ، فكرة جيدة. لا فكرة عن كيفية عمل filter_out في Makefile. التحقيق الأسوأ. شكرا على الاكرامية.

langou في ١٧ فبراير ٢٠٢١

TESTING / EIG / Makefile ، بعد إضافة include ../../make.inc

FFLAGS := $(filter-out -frecursive -Mrecursive,$(FFLAGS))
FFLAGS_DRV := $(filter-out -frecursive -Mrecursive,$(FFLAGS_DRV))
LDFLAGS := $(filter-out -frecursive -Mrecursive,$(LDFLAGS))

ل cmake سيكون شيء من هذا القبيل
string(REGEX REPLACE "-(fM)recursive" "" FFLAGS ${FFLAGS})
(غير مختبرة)

martin-frbg في ١٧ فبراير ٢٠٢١

👍1

شكرا @ Martin-frbg! سأختبرها الآن

weslleyspereira في ١٧ فبراير ٢٠٢١

هل كانت هذه الصفحة مفيدة؟

0 / 5 - 0 التقييمات