Discussion :

[Trap D]

Bonjour
En ce moment je découvre Rust et je dois dire que j'aime bien. La rapidité du C, un typage sérieux des arguments, une bibliothèque bien fournie de fonctions prédéfinies ...
Le gros problème est la différence à l'exécution des programmes sous Windows et Linux !
J'ai écris un programme de résolution de puzzle qui utilise la récursion avec des appels imbriqués.
Sous Windows le programme crash lamentablement au bout de 5/6 appels alors qu'il fonctionne parfaitement sous Linux/Fédora (plus d'une centaine d'appels).
Existe-t-il une solution à ce problème. J'ai un peu chercher sur le web, mais je n'ai rien trouvé.
Merci pour toute réponse.

[plegat]

Salut,

Sous Windows le programme crash lamentablement au bout de 5/6 appels alors qu'il fonctionne parfaitement sous Linux/Fédora (plus d'une centaine d'appels).
Existe-t-il une solution à ce problème.

Tu aurais des détails?
Compilateurs respectifs windows/linux?
Debug ou release?
Utilisation de quels crates?
Un message d'erreur? (crash mémoire genre stack overflow?). Apparemmet il y aurait une différence de traitement de la taille du stack entre windows et linux, mais je n'ai rien de concret sous la main pour le moment...

[Trap D]

J'ai un peu regardé les empilements de récursion,
Sous Windows (avec VS code ou Visual Studio, je ne sais pas si les compilateurs sont les mêmes), j'ai 6 empilements en mode debug et 13 en mode release.
Sous Fédora avec VS Code, j'en ai 66 en mode debug.
Le message d'erreur est "thread 'main' has overflowed its stack"
Comme je le disais, je débute donc je ne sais pas si j'utilise des crates particuliers, je n'ai que le "use std::io;".
J'ai regardé sur S.O., pas de question particulière sur ce problème, à croire que les gens ne font du rust que sous Linux !!
J'ai simplement vu que c'est l'OS qui fournit la taille pour l'exécution du programme, il n'est pas généreux pour rust car mon exécutable fait 308 ko en debug et 191 en release.
Je me semble me souvenir qu'on pouvait demander au système d'exploitation d'augmenter la taille de la pile d'exécution (tout au moins sous Windows) mais je n'ai pas retrouvé la commande. Sans doute mal cherché !
En tout cas, je continue à chercher et à diminuer la taille de mes données !!!

[plegat]

J'ai regardé sur S.O., pas de question particulière sur ce problème, à croire que les gens ne font du rust que sous Linux !!

Non, non, je suis sous windows, mais j'évite la récursion!
C'est un peu embêtant de risquer un stack overflow avec un langage sensé privilégier et garantir l'intégrité de la mémoire... hors avec la récursion, tu ne sauras pas prévoir ton besoin mémoire à la compilation. Et si tu sais le prévoir, c'est que tu n'as pas besoin de la récursion (ou tout du moins que tu peux t'en passer), et qu'il vaut mieux basculer sur un algo itératif (qui ira taper dans le tas et pas dans la pile).

(après, c'est facile à écrire, pas forcément simple à mettre en oeuvre sur un coup de tête!)

Regarde ça pour voir:
https://www.reddit.com/r/rust/commen...he_stack_size/ (définir la taille de la pile du thread principal à la compilation)

et https://stackoverflow.com/questions/...g-compile-time (définir la taille de la pile au runtime en passant par un nouveau thread)

[Trap D]

Merci pour les liens qui m'ont permis de trouver la solution !
Ça marche impeccable avec ce petit hack :

Code rust :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
const STACK_SIZE: usize = 768 * 1024 * 1024;
 
fn main() {
    // Spawn thread with explicit stack size
    let child = thread::Builder::new()
        .stack_size(STACK_SIZE)
        .spawn(run)
        .unwrap();
 
    // Wait for thread to join
    child.join().unwrap();
}

La fonction run est maintenant l'ancien main du programme !