Lapack: Erreur de segment dans ./EIG/xeigtstz

Créé le 19 avr. 2019  ·  11Commentaires  ·  Source: Reference-LAPACK/lapack

Salut,

c'est avec Lapack 3.8.0.

Une erreur de segmentation se produit dans xeigtstz avec lapack 3.8.0 et gfortran récent :

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

Cela disparaît lorsque la limite de pile est augmentée de la valeur par défaut de 8192 ko à 81920 ko (le
première valeur que j'ai essayée).

Build System Testing

Tous les 11 commentaires

gfortran9 signale un accès hors limites dans (entre autres) TESTING/EIG/zhet21.f ligne 304 (faites une boucle sur J allant de 1 à N-1, accédant à l'élément de tableau U(1, J-1 ) ... Aie). Je ne sais pas encore si c'est la cause réelle et unique de ce problème...
EDIT: mon observation n'est pas liée (et j'avais en fait manqué que vous ayez déjà ouvert # 333 pour cela) xeigtstz essaie d'allouer environ 10 Mo sur la pile pour les tests NEP comme déjà indiqué dans https://github.com/xianyi/OpenBLAS/ numéros/1645

définir ulimit -s 16384 au lieu du 8192 par défaut a également résolu ce problème pour moi

Même problème ici #85.

La solution idéale pour ce problème a été d'augmenter la limite de pile, mais puisqu'il s'agit d'un test, l'allocation de tas ne serait-elle pas une meilleure solution ?

Je pense que ce sont des tableaux allouables qui se retrouvent sur la pile en raison de l'option 'récursive' (requise pour la sécurité des threads) mais je n'ai pas encore réussi à trouver une solution de travail.

@weslleyspereira essaiera de compiler uniquement zchkee.f sans l'option -frecursive. Ainsi, tous les fichiers (en particulier liblapack.a) seront compilés en utilisant l'option -frecursive, mais zchkee.f sera compilé sans l'option -frecursive. Nous pensons/espérons que cela fera l'affaire. Nous testerons. Je pense qu'il est important de compiler LAPACK avec -frecursive. Maintenant, zchkee.f peut être compilé sans. Ce sera très bien. CMake et make auront l'air un peu plus laids. Je pense que nous attendons depuis longtemps une nouvelle suite de tests, nous suggérons donc que nous fassions les choses moche pour le moment et que nous nous concentrions sur une nouvelle suite de tests.

A fonctionné pour moi tant que je n'utilisais pas aussi OpenMP, mais ce dernier implique malheureusement -frecursive
(Peut utiliser filter_out dans Makefile pour supprimer frecursive/Mrecursive de FFLAGS, donc pas beaucoup de nouvelles laideurs)

A fonctionné pour moi tant que je n'utilisais pas aussi OpenMP, mais ce dernier implique malheureusement -frecursive

Ah. Oui, c'est un problème potentiel.

(Peut utiliser filter_out dans Makefile pour supprimer frecursive/Mrecursive de FFLAGS, donc pas beaucoup de nouvelles laideurs)

Ah, bonne idée. Aucune idée du fonctionnement du filter_out dans Makefile. Pire enquête. Merci pour le conseil.

TESTING/EIG/Makefile, après l'ajout include ../../make.inc

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

pour cmake ce serait quelque chose comme
string(REGEX REPLACE "-(fM)recursive" "" FFLAGS ${FFLAGS})
(non testé)

Merci @martin-frbg ! je vais le tester maintenant

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

Peter9606 picture Peter9606  ·  7Commentaires

JHenneberg picture JHenneberg  ·  10Commentaires

christoph-conrads picture christoph-conrads  ·  26Commentaires

weslleyspereira picture weslleyspereira  ·  5Commentaires

5tefan picture 5tefan  ·  3Commentaires