Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

lv_task_handler can fail to return in high load scenarios, causing watchdog resets

Ouverte
#2,124 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
35/100
Type d'issue
Bug
Clarté
À clarifier
Activité
À l'abandon

Piste de recherche

Commencez par suivre lv_task_handler et l’interaction entre DisplayApp/SystemTask décrite dans l’issue, puis reproduisez le blocage sous une charge d’animation élevée avec une LV_DISPLAY_REFR_PERIOD plus courte. Le travail est terminé lorsque le gestionnaire de tâches retourne sous une charge soutenue et que la file de messages ne provoque plus de réinitialisations du watchdog.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug

The LVGL task handler re-evaluates higher priority tasks after executing lower priority ones
The animation task is higher priority than refresh tasks
If the animation task or refresh task takes a long time, after executing the refresh task the animation task may be ready again
This causes lv_task_handler to infinitely execute animation->refresh->animation->refresh etc without ever returning
If lv_task_handler doesn't return, the DisplayApp message queue becomes full (usually with touchscreen events) and blocks SystemTask, causing watchdog resets

This happens very rarely or even never in standard InfiniTime. But by either decreasing the LV_DISPLAY_REFR_PERIOD and increasing animation load (e.g animation scroll speed for labels in px/s) (I have not tested if both are required to trigger this behaviour, but I know that both are sufficient), it's possible to reproduce this lockup.

I'd suggest that we replace the LVGL task handler with one that provides a hard upper bound on the number of task executions. Perhaps by only executing each task once and exiting early if it's already spent too long doing work (many tasks waiting)? This would allow task priorities to still be usefully enforced. Lower priority refresh tasks might still get starved by animations though.

Possible cause for #2012 (the notification header scrolling animation)

Langage dominant
C
Étoiles
3.4k
Forks
1.1k
Merge moyen
13 h 32 min
PR mergées (30 j)
2

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de InfiniTimeOrg/InfiniTime

Toutes les issues de InfiniTimeOrg/InfiniTime

Issues similaires

Plus d'issues C

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.