L'hypothèse était que chaque qCInfo bloquait le thread de décision sur une
écriture SQLite sous verrou. Mesurée sur la cible, elle ne tient pas — et deux de
ses prémisses étaient fausses.
CE QUI ÉTAIT FAUX. (1) `qCInfo` ne passe PAS par le LogEngine : il va au
gestionnaire de messages, qui écrit sur stdout. Le chemin `Logger::log()` →
`logEvent()` est celui des états et actions journalisés, déclenché par des
changements d'état. Deux chemins, deux coûts. (2) Le LogEngine de la cible est
LogEngineInfluxDB : `logEvent()` empile dans m_writeQueue et poste en asynchrone.
Rien n'y bloque le thread appelant. Le .sqlite du rapport était celui du harnais
de test, pas de la box.
MESURÉ sur Pi Zero 2 W, banc croisé arm64 lié à libnymea, gestionnaire de nymea
installé, stdout sur la socket journald — les conditions de nymead :
· catégorie active, vers journald : 69,4 µs / ligne
· catégorie active, vers /dev/null : 61,9 µs / ligne
· catégorie éteinte : 0,0045 µs / ligne
L'I/O n'est pas le coût : 8 µs sur 70. Le reste est du formatage. Et le cycle
d'arbitrage tourne à 60 s exactement pour ~30 lignes — soit 2,1 ms par cycle,
0,0035 %. Il faudrait 143 lignes par seconde soutenues pour atteindre 1 %.
Donc : ce n'était pas un argument pour le rapport, et l'y mettre sans mesurer
l'aurait affaibli. Une première estimation en Python donnait 11 µs/ligne — six
fois trop bas, parce qu'elle ne mesurait que l'écriture et pas le formatage. Le
banc en Qt, lié à la vraie bibliothèque, était le seul moyen d'avoir le chiffre.
MAIS UN DÉFAUT RÉEL EN SORT, petit et chiffré. nymeaLogMessageHandler construit
`messageString` — dont un QDateTime::toString — POUR CHAQUE MESSAGE, alors qu'elle
ne sert que si un fichier journal est ouvert. Mesuré isolément : 28,0 µs, soit
40 % du coût d'une ligne. Et nymead tourne sans fichier journal dans le service
livré (`ExecStart=/usr/bin/nymead -n`, aucun descripteur .log ouvert) : ces 28 µs
sont jetés à chaque message, sur toute installation en configuration par défaut.
Correctif d'une accolade : construire messageString sous `if (s_logFile.isOpen())`.
Ajouté en troisième demande du rapport, explicitement indépendante du plantage.
L'hypothèse « durée de vie du Logger vis-à-vis des événements postés » est FAUSSE.
Ce n'est pas un usage après libération : c'est un déréférencement de nullptr, et
la garde censée l'empêcher interroge un ensemble différent de celui qu'elle
protège. Correctif d'une ligne.
ÉTABLI, avec les symboles 1.15.2 (identifiants de build vérifiés) :
· #0 libnymea.so.1 + 0x14ea24 → Logger::log(...), logger.cpp:55
· #1 libnymea-core.so.1+0x1edae6 → la lambda de ThingManagerImplementation::
executeAction connectée à finished
· rdi = 0x0 au signal. Dans l'ABI SysV AMD64, rdi porte le premier argument,
donc `this`. Logger::log a été appelée sur un pointeur NUL — un usage après
libération donnerait une adresse quelconque, pas zéro.
LE MÉCANISME. La lambda fait `m_actionLoggers.value(clé)->log(...)`, et
QHash::value() rend nullptr sur une clé absente. Sa garde est
`thing->loggedActionTypeIds().contains(...)` — la liste DU THING, pas la TABLE
des journaliseurs. Au retrait d'un Thing, unregisterActionLogger vide la table
pendant que la liste du Thing reste intacte. La connexion prend `this` (le
ThingManager) pour contexte, donc un `finished` déjà posté survit au retrait :
garde vraie, table vide, nullptr déréférencé.
C'est notre défaut récurrent, dans du code amont : UN GARDE-FOU QUI INTERROGE LE
MAUVAIS OBJET. Il a l'air de protéger l'accès qui suit et n'a aucun rapport avec
lui — d'où son invisibilité à la relecture.
Et ce n'est pas limité aux tests : toute suppression de Thing pendant qu'une
action est en vol ouvre la même fenêtre en production, qu'une action longue
élargit.
SYMBOLISÉ SANS RIEN INSTALLER, et sans privilèges : `apt-get download` puis
`dpkg-deb -x`, et `addr2line` sur les fichiers extraits. Noté dans le rapport,
parce que c'est aussi la voie qui ne touche pas la machine. gdb, lui, ne peut pas
produire de pile ici : le binaire de test et le plugin ont été reconstruits depuis
le plantage, donc leurs identifiants ne correspondent plus au vidage. La
résolution par offset dans les bibliothèques reste valide, et suffit.
RÉSERVE ÉCRITE : les symboles sont ceux de 1.15.2, mais le code cité est lu dans
l'arbre 1.16.0, seule source locale. Les deux symboles s'y retrouvent à
l'identique ; la formulation exacte du correctif reste à vérifier sur la branche.
LEÇON GRAVÉE (AGENTS.md, à côté de la règle des identités) : entre deux instants
du MÊME fuseau, la soustraction rend la durée d'horloge murale, jamais la durée
réelle — donc un contrôle qui cherche les journées de 23 ou 25 h avec cette
arithmétique rend 24 h partout et conclut qu'elles n'existent pas. Trois de mes
contrôles s'y sont trompés dans ce lot, sur la question même que le champ existe
pour régler.
La parade générale est la vraie leçon : l'attendu d'un test ne se calcule pas avec
les primitives du code testé. L'oracle du test de frontière vient de hors Qt ; le
re-dériver avec QDateTime aurait refermé l'identité sur elle-même — la faute que
la règle voisine traque, retrouvée un cran plus bas, non plus dans l'assertion
mais dans la fabrication de sa valeur attendue.
Vérifié plutôt que supposé. La version EXACTE qui a planté est encore au
dépôt nymea — indispensable, car des symboles d%sune autre version ne
résolvent pas un offset, ils le résolvent FAUX.
Trois points qui rendent l%sopération sûre : la version exacte existe ;
l%sépinglage évite la cascade (sans lui apt prendrait la 1.16.0 et mettrait à
jour toute la pile de développement) ; et ces paquets sont amd64, Section
debug, n%sinstallant que /usr/lib/debug — le banc est arm64 et ne peut pas
être affecté.
`sessionEnergy` est l'ACCUMULATEUR du plugin V2C, pas un compteur remis à
zéro pour le moteur : l'écart avec `chargeEnergy` est constant au
dix-millième (7,2044 kWh sur deux échantillons à deux heures d'écart), parce
qu'il porte les incréments d'avant la dernière remise à zéro de la borne.
Le lire directement ferait croire toute obligation éco tenue de 7,2 kWh dès
le premier cycle — un nombre crédible et faux que rien ne signalerait.
Contre-épreuve : lecture directe, le test annonce 7204.
La base se prend à l'ouverture de l'OBLIGATION, jamais au démarrage de
nymead : sinon un redémarrage en pleine session réinitialise l'avancement
sur une valeur déjà accumulée, et la recharge de nuit relue au matin repart
de zéro. Elle est RECAPTURÉE sur un recul franc de l'accumulateur — une
nouvelle session — mais pas sur un recul infime, qui est du bruit de lecture
et coûterait l'avancement acquis à chaque frémissement du compteur.
Ce que le moteur ne refait PAS : la détection de remise à zéro de la BORNE
vit dans le plugin, qui interroge à 30 s. Le moteur travaille à la minute et
raterait des cycles entiers. Lire comment le plugin l'avait écrite a évité
d'ajouter une seconde accumulation, moins fine, en concurrence de la
première.
Trois maillons manquants raccordés, tous déclarés et alimentés par personne :
EvCharger n'exposait pas sessionEnergy ; LoadContextTelemetry::sessionWh
n'était rempli nulle part ; et toLoadContext() ABANDONNAIT les besoins
déclarés, si bien que LoadContext::needs n'était rempli par aucun adaptateur.
L'obligation éco n'existait qu'en configuration.
Mock : sessionEnergy ajouté à chargerPhaseSwitching UNIQUEMENT — `charger`
reste sans, ce qui donne le cas unmeasurable nativement. La suite porte les
deux régimes, comme le banc.
Le régime est publié alors qu'aucune décision ne s'y appuie encore, et c'est
délibéré : cela sépare publier le régime de décider avec, comme measurement
l'a été de l'arbitrage, et rend R6 testable le jour où le motif naîtra au
lieu d'un invariant posé sur du code que rien n'émet.
Suite : simulation 56/56, charging 48/48 identique à la référence ligne à
ligne, loadmodel 21/21, spotmarket 32/32, doxygen 0 avertissement.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Patrick Schurig
