Pouvez-vous poster votre fichier source ?

J'attends que l'examen soit passé avant de diffuser les sources (vendredi 26/01)
Je n'ai pas réussi à reproduire le problème sur les sujets des années précédentes (sujets qui comportent moins d'équations).
A noter: la correction est possible avec 100 copie générées.

Bonjour,

Voila les sources:
https://fex.insa-lyon.fr/get?k=BcPS6YYPCZXAfCTaYo9
En 1.3.0, ça fonctionne pour 100 copie mais pas pour 850 (blocage à corriger)
En 1.2.1, ça fonctionne pour 850 copies

Merci

Avec la version 1.3.0, il faut 4 minutes pour passer de "Analyse barème" à "Calcul des notes". 36 minutes plus tard, le calcul des notes n'est toujours pas fait (abandon).

La première partie correspond au temps de la compilation avec LaTeX. Par contre, la deuxième partie devrait être bien plus rapide… Pouvez-vous essayer de lancer une correction en mode débogage (depuis le menu Aide) et joindre le fichier log produit ?

Je suis venu à bout de la correction en une nuit (plus de 3 heures, le lendemain patin c'était terminé donc je ne sais pas exactement combien de temps ça a pris).
Le fichier log est à la mesure de la tache: 45 Mo
Le voila:
https://fex.insa-lyon.fr/get?k=nM734E1UjU9Ehp7opQt

Le topic suivant est certainement lié au même problème: Temps de calcul des notes en version 1.3.0

Est-ce qu'il y a des problèmes de mémoire (et donc utilisation de swap) ? Pouvez-vous commencer l'opération et surveiller les premières lignes de l'affichage de top pendant l'exécution, au bout de 10 minutes environ ? %Cpu, Mem, Swap…

Voir la copie de htop ci-dessous.
Le CPU est assez souvent à 100%
1.1G sur 3.82G de mémoire utilisée
Jamais de swap
auto-multiple-choice prepare consomme presque exclusivement les ressources.

  1  [|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]   Tasks: 99, 343 thr; 3 running
  2  [||                                                                     2.0%]   Load average: 1.25 1.22 1.05 
  3  [|||||||                                                                7.9%]   Uptime: 03:20:21
  4  [||||                                                                   4.6%]
  Mem[||||||||||||||||||||||||||||||||||||||||||||||||||              1.11G/3.82G]
  Swp[                                                                   0K/3.97G]

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
 4221 ben        20   0 95444 46792  7016 R 99.5  1.2 22:39.22 auto-multiple-choice prepare
 4242 ben        20   0  328M 39684 28580 S  5.3  1.0  1:05.71 xfce4-taskmanager
 5075 ben        20   0 1864M  213M  132M S  4.0  5.5  0:04.58 /usr/lib/firefox/firefox -contentproc -childID 12 -isForBrowser -intPrefs 5:50|6:-1|18:0|28:1000|34:20|35:5|
 1158 root       20   0  438M  114M 63976 S  2.0  2.9  3:54.55 /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
 5036 ben        20   0 27036  4932  3220 R  0.7  0.1  0:01.07 htop
 5090 ben        20   0 1864M  213M  132M S  0.7  5.5  0:00.12 /usr/lib/firefox/firefox -contentproc -childID 12 -isForBrowser -intPrefs 5:50|6:-1|18:0|28:1000|34:20|35:5|
 5041 ben        20   0 1826M  158M   99M S  0.7  4.0  0:10.42 /usr/lib/firefox/firefox -contentproc -childID 11 -isForBrowser -intPrefs 5:50|6:-1|18:0|28:1000|34:20|35:5|
 1514 ben        20   0  360M 19364 16868 S  0.7  0.5  0:00.87 xfsettingsd
 2063 ben        20   0 2491M  404M  158M S  0.0 10.3  4:30.76 /usr/lib/firefox/firefox

Le problème de ce post est certainement le même:
https://project.auto-multiple-choice.net/boards/4/topics/6337

Est il possible que ce soit la correction évoquée ici qui refait surface?
https://project.auto-multiple-choice.net/boards/4/topics/1082

Quelques précision techniques:
Le test est fait sur la même machine
Test sur 1.3.0 avec ubuntu studio 16.04 et disque SSD: entre 3 et 8 heures pour la correction
Test sur 1.2.1 avec ubuntu 16.04 et disque dur mécanique: 2 minutes pour la correction

Le problème de ce post est certainement le même:
https://project.auto-multiple-choice.net/boards/4/topics/6337

Peut-être mais nous n'avons pas beaucoup d'informations sur celui-ci

Est il possible que ce soit la correction évoquée ici qui refait surface?
https://project.auto-multiple-choice.net/boards/4/topics/1082

Normalement non car l'index créé à cette époque est toujours présent dans la version actuelle. On peut le vérifier en ouvrant la base data/capture.sqlite avec sqlitebrowser : l'index capture_index_zone_nopage est bien présent.

Je viens de tester sur openSUSE 42.2 en AMC 1.3.0: 8 minutes de correction donc ça fonctionne. C'est 4 fois plus long mais pas sur la même machine donc difficile de tirer des conclusions.
Mes hypothèses: noyau linux ou dépendances.
J'essaye de faire des autres tests.

La suite:
Sur ubuntu studio 16.04

Downgrade de 1.3.0 vers 1.2.1 puis recompilation à partir des sources latex: la correction fonctionne correctement en 2 minutes
Upgrade de 1.2.1 vers 1.3.0 puis recompilation à partir des sources latex: la correction fonctionne correctement en 2 minutes
En 1.3.0 (downgrade+upgrade), si j'utilise le dossier original(avant downgrade+upgrade), le bug de la correction longue se reproduit.

Difficile de dire comment est apparu ce problème: problème d'installation AMC, base de données corrompue, migration openSUSE<->ubuntu

Je joins le dossier AMC corrompu:
https://fex.insa-lyon.fr/get?k=bGVk3TxO80vAtAmHGad

Plus de problème pour moi mais ce serait intéressant de savoir comment est apparu ce problème.

• la notation bloque (mêmes symptômes que vous) en partant de votre archive telle quelle ;
• la notation fonctionne en partant de votre archive à laquelle on enlève le fichier automultiplechoice.sty.

Merci beaucoup pour ce retour.
J'étais encore loin de trouver la solution tout seul!
automultiplechoice.sty est issu de la rédaction collaborative. Les collégues qui rédigent les parties le font sur texmaker sur windows et ont besoin de automultiplechoice.sty
Peut on laisser sans risque la version courante de automultiplechoice.sty dans le dossier ou faut-il supprimer dans tous les cas?

La version courante peut être laissée, mais il viendra peut-être un jour où elle ne sera plus la version courante.
Avec la version de développement d'AMC, un test est effectué à l'issue de la préparation des documents pour vérifier que la version du fichier sty utilisée est celle d'AMC. Dans le cas contraire, l'utilisateur est averti. Par contre, avec votre dossier, cet avertissement arrive… après le blocage.