Non, erreur fatale signifie que ça a planté. Les tests sont de plus en plus gros, donc si tu avais un dépassement de bornes quelque part, il se peut que le fait que le test soit plus gros te fasse sortir des endroits où tu as normalement le droit d'écrire en mémoire...
Ecris toi un générateur de tests pour pouvoir tester avec une entrée de taille maximale !
???
Tu écris que les tests plus gros pourrait me faire sortir des endroits où j'ai normalement le droit d'écrire en
mémoire, tu insinue donc que je dépasse la limite de mémoire et donc tu ne réponds pas a la question : Pourquoi il ne me
dit pas mémoire dépassé.... ?
moi je pense plutot que le test qui te fait planter est un test sournois, très différent d'une chaine aléatoire, qui est justement là pour taquiner la solidité de ton algo... je vois pas d'autres raisons, erreur fatal ça veut bien dire que ça plante...
Non, le test n'est pas sournois, il est juste gros. Je ne dis pas que tu dépasses la limite de mémoire, mais que tu écris à un endroit non autorisé (erreur de segmentation). Ce n'est pas la même chose. Tu peux chercher à écrire plus loin dans la mémoire sans en allouer plus.
bon j'ai testé sur mon ordi, avec une chaine de 200 000 caractere et en recherchant une chaine de 15caractere... :
\~\$ time ./exe
AAATAGACAGCTTAT
real 0m0.443s
user 0m0.376s
sys 0m0.064s
ET SA PLANTE PAS !!!!
Donc .... je ne sais pas ou chercher le problème chez moi ça marche ....
Essaie de générer plusieurs tests (pas juste un qui peut ne pas montrer une faille...), et si tu n'y arrives toujours pas, tu peux essayer de lancer ton programme sous valgrind qui devrait te détecter ton erreur. En dernier recours, tu peux toujours nous envoyer ton code pour qu'on le regarde... (entraineur chez ml point prologin point org)
PS. Sa et ça, ce n'est pas la même chose.
Bon, ben... c'est encore moi =/
Et en plus, je vais pas ajouter grand-chose au débat, puisque j'ai exactement la même erreur que mattgu74. J'ai une "erreur fatale", sans plus d'explications, alors que je viens de faire exactement 1200 tests avec une chaîne de taille maximale, et la taille de la sous-séquence recherchée variable. Le programme est rapide (12 secondes pour 1000 tests...) et chez moi en tout cas, il est fiable.
le seul indice de "dysfonctionnement", serait que pour des chaînes de taille comprise entre 7 et 9, j'obtiens relativement souvent (une fois sur 10 environ) des renvois du type "GGGGGGG" ou "AAAAAAAAA". C'est curieux, mais je ne sais vraiment pas du tout à quoi cela peut être dû ni en quoi ça peut m'aider. Sur le papier, ça devrait marcher à merveille et ça m'agace de me dire que ça doit être un problème technique et non algorithmique qui est à l'origine de mes ennuis.
Deux questions :
Merci d'avance.
Non non, loin de là. Il n'y a pas besoin de réussir tous les exos parfaitement. L'année dernière j'avais l'exo 3 qui passait pas le dernier test et pour l'exo 4 j'avais filé une solution loufoque, j'ai été qualifié quand même. ;)
Il n'y a pas besoin de tout réussir pour être qualifié. Mais c'est toujours bien de savoir faire ce genre de choses, ça vous servira plus tard !
Pour ton bug, as-tu essayé de déboguer avec Valgrind par exemple, pour voir si tu n'as pas d'erreurs de gestion mémoire ? (qui peuvent être révélés par le changement d'architecture entre le serveur et chez toi...)
Hm, je sais pas trop utiliser Valgrind, et je sais pas si j'ai le temps de manger les kilomètres de manuel avant le 3 janvier. Donc voilà le rapport que le logiciel m'a sorti :
valgrind --leak-check=yes ./Prologin3
==20363== Memcheck, a memory error detector
==20363== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==20363== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
==20363== Command: ./Prologin3
==20363==
==20363== Can't extend stack to 0xbe590390 during signal delivery for thread 1:
==20363== no stack segment
==20363==
==20363== Process terminating with default action of signal 11 (SIGSEGV)
==20363== Access not within mapped region at address 0xBE590390
==20363== at 0x80483B9: P\$PROLOGIN3_TRIRAPIDE\$TTAB\$SMALLINT\$SMALLINT (Prologin3.pas:96)
==20363== If you believe this happened as a result of a stack
==20363== overflow in your program's main thread (unlikely but
==20363== possible), you can try to increase the size of the
==20363== main thread stack using the --main-stacksize= flag.
==20363== The main thread stack size used in this run was 8388608.
==20363==
==20363== HEAP SUMMARY:
==20363== in use at exit: 0 bytes in 0 blocks
==20363== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==20363==
==20363== All heap blocks were freed -- no leaks are possible
==20363==
==20363== For counts of detected and suppressed errors, rerun with: -v
==20363== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Erreur de segmentation
Que je ne comprends qu'assez moyennement, pour être franc. Est-ce un dépassement de pile dû à la récursivité du tri que
j'utilise ? Si oui, alors pourquoi est-ce que ça n'arrive qu'à moi, c'est dû au fait que je code en Pascal ? =/
Et pourquoi "Erreur de segmentation", alors que quand je le lance normalement ça n'arrive pas ?
Je vais essayer d'autres tris, je vous tiens au courant...
==20363== Access not within mapped region at address 0xBE590390
==20363== at 0x80483B9: P\$PROLOGIN3_TRIRAPIDE\$TTAB\$SMALLINT\$SMALLINT (Prologin3.pas:96)
C'est assez clair : tu fais un accès en dehors des bornes de ton tableau à la ligne 96 de ton fichier...
Hm, d'accord.
Je me flagellerai jusqu'à ce que les tailles des différents int, longint, etc... me rentrent dans le crâne.
J'ai fini par y arriver, dans la douleur et le sang, et c'était entièrement ma faute. Je suis juste toujours un peu étonné du fait que les messages d'erreur affichés "erreur fatale" ou autre étaient aussi peu clairs, normalement une de mes fonctions aurait dû me dire qu'il y avait un gros souci, j'essayais de donner à une variable une valeur qui était interdite car trop grande...
Il faut absolument que j'apprenne à me servir correctement des "try...except".
Toutes mes excuses...
Prologin
2024