Discussion :

[frederic13870]

Bonjour,

j'ai écris un programme qui, lors d'une boucle infinie, filme des vidéos de trois minutes.

Cela marche bien pendant presque une journée entière, puis le programme bloque sans
que je sache pourquoi.

Quand je fais ps -aux | more la tache est toujours présente en mode sleep, mais bloquée à une certaine heure.

J'utilise la commande raspivid pour la vidéo.

Est-ce un problème mmal ou autre ?

Comment savoir ?

[Sve@r]

Bonjour

Ca ressemble à une saturation mémoire.

Comment savoir ?

Du printf() dans la boucle. Regarder le retour des fonctions systèmes, la valeur de errno. Peut-être rajouter du sleep pour laisser au bouzin le temps de se reposer...

[frederic13870]

Peut-être puis-je paramétrer la mémoire avec raspi-config et faire un essai ?

Je ne fais pas de malloc, mais utilise un tableau de grande taille ...

Le problème est que je lance le programme en tache de fond avec une commande

Code :

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

1
2
 
nohup ./camera -i 10 -d 5 &

i étant le nombre d'images par seconde et d la durée d'enregistrement en jours.

[gerald3d]

Bonjour.

Je rejoins Sve@r sur un problème de dépassement de tampon.

Même si tu n'alloues pas de mémoire dans le tas, la pile a une taille limitée. Elle est réglable de mon souvenir dans le système d'exploitation.

Plutôt que de lancer ton application "à l'infini" pourquoi ne pas la lancer avec crontab. Tu choisis l'intervalle de temps pour chaque lancement et une exécution enregistre 3 minutes.

[Sve@r]

Je ne fais pas de malloc, mais utilise un tableau de grande taille ...

grande taille ça veut tout dire et rien dire à la fois. Mais malloc pourrait avoir une utilité dans la mesure où lui il bosse dans le tas et non dans la pile (plus réduite). Ceci dit, dans la mesure où tu ne fais pas de VLA (j'espère) et que ton tableau est défini hors de la boucle, ça ne devrait pas influer (et même s'il est défini dans la boucle, chaque itération terminée libère la mémoire)

Le problème est que je lance le programme en tache de fond avec une commande

Code :

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

1
2
 
nohup ./camera -i 10 -d 5 &

T'as une sortie dans "nohup.out". Si tu rajoutes des témoins dans la boucle tu auras un résultat utilisable.

[Bousk]

Et le code est ?
Ce serait pas la première fois que je vois un truc boucler sur un ensemble et exploser quand on ajoute des choses dedans.

[frederic13870]

J'aimerai être sur qu'un module du noyau, ou le noyau lui-même, ou bien le matériel n'est pas en cause.

Pour cela, je fait des

Code :

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

sudo dmesg -kH

Et je trouve régulièrement des erreurs.

Voulez-vous que je vous les montre ?

[LittleWhite]

Les messages renvoyés par dmesg comprennent les erreurs de segmentation des programmes en espace utilisateur, surement pour signaler à l'administrateur qu'un utilisateur/programme est entrain de faire des trucs crades, mettant en question la sécurité.
Mais peut être il y a des messages intéressants, je dis pas.

[frederic13870]

Je crois que le mieux est de refaire le programme de A à Z.

Les outils de débuggage à l'execution ne sont pas légion pour le gcc.

Quand ce genre de problèmes arrive, je crois que le mieux est de tout re-écrire et tester au fur et à mesure.

Ah , au fait ! Savez-vous dans quel répertoire système sont situés les includes en C ?

Je me souhaite bon courage !

[WhiteCrow]

Je crois que le mieux est de refaire le programme de A à Z.

Bonjour,
je ne sais pas …

Les outils de débuggage à l'execution ne sont pas légion pour le gcc.

Alors gcc permet d'embarquer des informations de debug dans les fichiers produits. Il y a plusieurs formats (gdb, stabs, COFF, XCOFF, ou DWARF) dans différentes versions. Ensuite il existe plusieurs debugers utilisables, ces debugers sont indépendants de gcc. Le plus connu est certainement gdb qui par défaut utilise une interface REPL, mais il existe de nombreux front-ends (DDD, nemiver …) ou plugin (VSCode, VS, Anjuta, Emacs, vim, …) et il est possible de faire du debug distant.
Ensuite c'est plus une question de disponibilité sur les plateformes utilisées.

Mais bon, il n'y a pas que les debuger pas à pas … il y a aussi le memory profilers comme valgrind pour les problèmes de gestion de mémoire par exemple.

Quand ce genre de problèmes arrive, je crois que le mieux est de tout re-écrire et tester au fur et à mesure.

C'est clair que tester pendant le dev c'est bien lol.
Tout réécrire ? ça dépend de l'état du projet.
Mais cela n'évitera jamais la phase de debug … avec gdb, valgrind, ou même de simples printf.

Ah , au fait ! Savez-vous dans quel répertoire système sont situés les includes en C ?

Je me souhaite bon courage !

Il faut demander à ton compilo où il va les chercher
Comme tu peux avoir plusieurs configurations … tu peux exécuter la commande gcc -xc -E -v /dev/null -o /dev/null qui te donneras une liste comme (extrait) :

#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include-fixed
/usr/include
End of search list.

Bon courage ????
Surtout bon apprentissage !!!

[frederic13870]

J'avais un problème de dépassement dans le code C.
Ach, ces chiennes de caractères ....