J’ai fait les tests de ma lib PHP sur gtest, j’espère que c’est pas moi qui ai tout cassé. 
Plus sérieusement, j’ai fait passé des TX en unitbase 0, et en V10, BMA me répond OK, si ça peut aider. 
Ça semble lié au correctif de la WoT de la 1.7.17.
Je pense pas que ça soit lié aux documents que tu as pu envoyer.
Il me semble que c’est correct. Les transactions sont en v10, et il doit être possible d’envoyer des sources en base 0 alors que la base courante et en base 1.
Donc, pas de souci de ce côté-là.
1 Like
Je confirme, la règle BR_G90 du protocole spécifie bien que les sources en base <= UnitBase sont valides :
Du coup y a t’il un nœud BMA en 1.7.17 sur lequel on peut se synchroniser ?
Aucun pour le moment, il faudra une version 1.7.18.
1 Like
j’ai un duniter-desktop en 1.7.17 sur lequel j’ai conf BMA en interface graphique rapidos. Je sais pas si c’est fonctionnel, ni utile.
scanlegentil.freeboxos.fr 20939
Vous pourriez me faire un retour juste pour savoir si ça peut servir à qqch, et satisfaire ma curiosité, svp?
http://scanlegentil.freeboxos.fr:20939/blockchain/current
ne répond pas chez moi… probablement un problème de config réseau…
idem 
Il s’agit d’une certification de moul-test vers MeluaTest qui n’est plus membre :
{ op: 'UPDATE',
issuer: '5B8iMAzq1dNmFe3ZxFTBQkqhq4fsztg1gZvxHXCk1XYH',
receiver: 'droYn565eApVvJFu18trt4qTiS8uFcVpd5TdwSUPQAT',
created_on: 220980,
written_on: '362833-0001C645558EA9FF0FFE95EA1C90B554A9C218426BD62D4247D03BD345A4F306',
writtenOn: 362833,
expired_on: 1556572064 }
5B8iMAzq1dNmFe3ZxFTBQkqhq4fsztg1gZvxHXCk1XYH −> droYn565eApVvJFu18trt4qTiS8uFcVpd5TdwSUPQAT
Avec l’outil explorateur de leveldb en CLI lev sur iindex :
/>get 5B8iMAzq1dNmFe3ZxFTBQkqhq4fsztg1gZvxHXCk1XYH
'[{"index":"IINDEX","op":"UPDATE","uid":"moul-test","pub":"5B8iMAzq1dNmFe3ZxFTBQkqhq4fsztg1gZvxHXCk1XYH","hash":"D03883E8E5EEB5B6DF11216FD9BD658A71E07D66D0F951534898DC7396B3EB2D","sig":"/15YBc4JDPvKD4c8nWD6C0XN0krrS32uDRSH6rJvMFih/H5nPc8oiCgL27bA7P3NPnp+oCqbS12QygQRnhoDDQ==","created_on":"167750-0000A51FF952B76AAA594A46CA0C8156A56988D2B2B57BE18ECB4F3CFC25CEC2","written_on":"350088-00008BBCF1FB5938221A742AD4504688606736410F33D99C22D52E203405CDDB","writtenOn":350088,"age":0,"member":true,"wasMember":true,"kick":false,"wotb_id":74}]'
>get droYn565eApVvJFu18trt4qTiS8uFcVpd5TdwSUPQAT
'[{"index":"IINDEX","op":"UPDATE","uid":"MeluaTest","pub":"droYn565eApVvJFu18trt4qTiS8uFcVpd5TdwSUPQAT","hash":"C4588D77602891658C855BDA3A9C6233AE6CE20ABB05673E08524DC0C75015DA","sig":"yUHE3j5OhMOUqtPe7HvxcD3IaZig0JuSqnYtcVxubdgL28hPJlTWZ6haLNV2zcSN89/D+r2NR7q4vNvStaUdBA==","created_on":"139407-0000283A55F7998974D64AD54DF11EB365F5D18301C023944CF2BFC03A24C126","written_on":"323745-000023570007021D1BF52C9DBB10699F6CCEE378231CD5D36CB67E21CF68E1AE","writtenOn":323745,"age":0,"member":false,"wasMember":true,"kick":false,"wotb_id":55}]'
Ça segfault à cette ligne lors du retrait de ce lien de certification :
Je sais pas si le code de wotb est en faute à cet endroit, ou si la base de donnée des liens wotb.bin qui devait contenir ce lien. Le lien dans wotb a surement du être supprimé au préalable.
Le lien est toujours présent dans cindex :
get droYn565eApVvJFu18trt4qTiS8uFcVpd5TdwSUPQAT
'{"received":["C4pUj26pVgPVPLEZ962LHmCAED7vs4FSBMGQFNDSYtXG","7KL2QXXFULDpsQY4UdSr5oEVx6rFE6oxeagRdkCX35bf","9Uwy2bEbYUiUfB6SVrkhGheEiuBr6TSh6bD8AH8dajy7","3dnbnYY9i2bHMQUGyFp5GVvJ2wBkVpus31cDJA5cfRpj","E8Ah8g9vpK7x52Bt4Mzmz9f2rdp7j1dxdgcGiSkpMJ4y","2Jfw9Me5KYbQ3rH8ncSqXUUfaai93e5vq9jW6REsAGZz","9nc3atrvLRvVWDM3sCRHTUnA6eipwuT34oBXdpFhRu1R","68jjsRrrX6hzs4z6eK2A2MUGLdKPfysFd1n3DYfHr7X9","d88fPFbDdJXJANHH7hedFMaRyGcnVZj9c5cDaE76LRN","5B8iMAzq1dNmFe3ZxFTBQkqhq4fsztg1gZvxHXCk1XYH","GF5i8XE2EdYyFKvpD2FhFYSvwqHXGSD5jTG9fe1imtPu","J8sxV22rNKHa2FLAdMsvqRdNfmm67i24DVYKN6D5Rm8C","28zNwPNHsCqoZPmejk4w21p6CKerN7CCMvhejRbAEyiz","DpJse2t7fyH9LC9FTMQHsMGZToXLmVQ8EV2eP47ipHDC"],"issued":[{"index":"CINDEX","op":"CREATE","issuer":"droYn565eApVvJFu18trt4qTiS8uFcVpd5TdwSUPQAT","receiver":"3THvswEGNFDdteyCYypkxViXdbkVsgirQZzHxRWZ5bLL","created_on":310548,"written_on":"310550-00002F7308A3B48BE3895AE3E8993F2E9F8F65C03847E9F9BD6AF40568A314D6","writtenOn":310550,"age":183,"stock":100,"unchainables":0,"sig":"QVb/VgiaYruDeN9w2LPvqWkrQVxYVXFq56s5eCSJCaNjCJ+mcSdPbsevhyPoVhko1YQ2bfQ4A53nBGaCxngQDA==","chainable_on":1548088430,"replayable_on":1549053950,"expires_on":1560624714,"expired_on":0,"from_wid":null,"to_wid":null}]}'
Si la théorie selon laquelle ce lien aurait été supprimé au préalable par Duniter, ça a pu se passer ici :
dal/fileDAL.ts:1084: wotb.removeLink(from.wotb_id, to.wotb_id);
blockchain/DuniterBlockchain.ts:379: dal.wotb.removeLink(from.wotb_id, to.wotb_id);
indexer.ts:2057: tempLinks.forEach((link) => wotb.removeLink(link.from, link.to));
Maintenant, va trouver pourquoi Duniter a demandé deux fois à wotb de supprimer ce lien.
Il faudrait creuser plus, mais je vous livre dès à présent l’analyse.
4 Likes
C’est la bonne piste.
De ce que je vois, le compte moul-test a réalisé deux certifications vers MeluaTest :
~/.config/duniter/duniter_default/g1-test$ rgrep 5B8iMAzq1dNmFe3ZxFTBQkqhq4fsztg1gZvxHXCk1XYH:droY
chunk_883-250.json: "5B8iMAzq1dNmFe3ZxFTBQkqhq4fsztg1gZvxHXCk1XYH:droYn565eApVvJFu18trt4qTiS8uFcVpd5TdwSUPQAT:220980:XmvUCsUzPkUQJydhDaBu1ekN2hYTfOSneyxdoAmcCQdu+BO0UPtnmfLYyqOehl3BGe1YDZAqr7BV4Javy7tkDQ=="
chunk_1142-250.json: "5B8iMAzq1dNmFe3ZxFTBQkqhq4fsztg1gZvxHXCk1XYH:droYn565eApVvJFu18trt4qTiS8uFcVpd5TdwSUPQAT:285599:mpLb7t4wC9NnrZ2OkAT75ZYpd9u/I4uA+sSeEpOva4eHzj9wlFaaNHkPBeVzjPcfObr7udkCrLoFMrUVP671DQ=="
En regardant les timestamps des blocs d’écriture, ça donne :
- cert#1 : le 30/7/2018 à 14:47:25 (expire 146 jours plus tard, ~ le 23/12/2018)
- cert#2 : le 03/12/2018 à 8:52:23 (expire 146 jours plus tard, ~ le 28/04/2019)
En regardant les logs de la synchro, j’observe :
[...]
2019-04-30T13:08:44+02:00 - info: Getting chunck #1451/1451 from 362750 to 362834 on peer g1-test.duniter.org
2019-04-30T13:08:45+02:00 - debug: Total tx count: 88282
2019-04-30T13:08:45+02:00 - debug: Total tx count: 88282
2019-04-30T13:08:45+02:00 - debug: Total tx count: 88282
2019-04-30T13:08:45+02:00 - trace: removeLink 74 -> 55
2019-04-30T13:08:45+02:00 - trace: removeLink 6 -> 81
2019-04-30T13:08:45+02:00 - debug: Total tx count: 88282
2019-04-30T13:08:45+02:00 - debug: Total tx count: 88283
2019-04-30T13:08:45+02:00 - info: Mem2File [wotb]...
2019-04-30T13:08:45+02:00 - info: Block #362708 added to the blockchain in 21 ms
2019-04-30T13:08:45+02:00 - info: Block #362709 added to the blockchain in 18 ms
[...]
2019-04-30T13:08:48+02:00 - info: Block #362832 added to the blockchain in 24 ms
2019-04-30T13:08:48+02:00 - trace: removeLink 74 -> 55
/usr/bin/duniter : ligne 15 : 14304 Erreur de segmentation (core dumped) $NODE "$DUNITER_DIR/bin/duniter" "$@"
J’y vois plusieurs choses :
- On voit effectivement deux fois le
removeLink 74 -> 55 - Le second removeLink apparaît au bloc#362832
- Le premier removeLink intervient juste avant les deux dernières occurrences de
Total tx count, ligne de log envoyée à la fin de l’interprétation d’un lot de blocs, donc ça correspondrait (étant donné le dernier n° de lot visible ici, #1451), à un bloc du lot #1449 ou proche. De toute façon chaque lot est de 250 blocs, soit les blocs de moins d’une journée, donc on peut déduire que le premier removeLink est intervenu dans les 2 derniers jours. Ce qui correspond à ~28/04/2019.
Cette date correspond à l’expiration attendue du cert#2, et il est par ailleurs tout à fait conforme que ce removeLink ne soit pas intervenu plus tôt pour cert#1, puisque cert#2 est un rejeu qui repousse donc la suppression du lien. Mais alors, pourquoi un second removeLink apparaît ensuite ?
Je ne le sais pas encore, continuons de creuser, Moul 
4 Likes
Bon, j’ai trouvé la cause. Si tu la trouves aussi @Moul, je devrais te tirer mon chapeau. Là c’est du niveau Cœur de Ğ1++ !
Je te laisse chercher un peu, tu nous diras où t’on mené tes dernières investigations 
tu peux aussi donner ta langue au chat, mais quoi qu’il en soit je ne pousserai de correctif que demain soir car je veux poser un test verrou.
3 Likes
J’ai peu être un correctif, mais je ne suis pas sûr que ça soit correct étant donné que ça me paraît trop simple en vu du niveau de difficulté que t’as donné à l’exercice.
Le correctif peut également être à l’endroit où est assigné la variable op de la certification, mais je n’ai pas trouvé cet endroit.
La synchronisation n’a pas engendré de segfault :
2019-05-02T00:00:23+02:00 - ^[[32minfo^[[39m: Block #362829 added to the blockchain in 28 ms
2019-05-02T00:00:23+02:00 - ^[[32minfo^[[39m: Block #362830 added to the blockchain in 18 ms
2019-05-02T00:00:23+02:00 - ^[[32minfo^[[39m: Block #362831 added to the blockchain in 19 ms
2019-05-02T00:00:23+02:00 - ^[[32minfo^[[39m: Block #362832 added to the blockchain in 44 ms
2019-05-02T00:00:24+02:00 - ^[[32minfo^[[39m: Block #362833 added to the blockchain in 36 ms
2019-05-02T00:00:24+02:00 - ^[[32minfo^[[39m: Block #362834 added to the blockchain in 28 ms
2019-05-02T00:00:24+02:00 - ^[[32minfo^[[39m: Block #362835 added to the blockchain in 21 ms
Je sais pas comment avoir tous les journaux de synchronisation (mon fichier contiens que la fin).
Et le correctif sous forme de patch :
diff --git a/app/lib/dal/fileDAL.ts b/app/lib/dal/fileDAL.ts
index ea1b1002..f14e8aa5 100644
--- a/app/lib/dal/fileDAL.ts
+++ b/app/lib/dal/fileDAL.ts
@@ -1072,10 +1072,11 @@ export class FileDAL {
for (const entry of cindex) {
const from = await this.getWrittenIdtyByPubkeyForWotbID(entry.issuer);
const to = await this.getWrittenIdtyByPubkeyForWotbID(entry.receiver);
if (entry.op == CommonConstants.IDX_CREATE) {
// NewLogger().trace('addLink %s -> %s', from.wotb_id, to.wotb_id)
wotb.addLink(from.wotb_id, to.wotb_id);
- } else {
+ } else if (entry.op != CommonConstants.IDX_UPDATE) {
// Update = removal
NewLogger().trace('removeLink %s -> %s', from.wotb_id, to.wotb_id)
wotb.removeLink(from.wotb_id, to.wotb_id);
Explication : donc supprimer le lien dans le cas où il ne s’agit pas d’une opération CREATE, ni d’UPDATE. Mais quelle opération reste-t-il pour supprimer le lien ?
Voilà pourquoi je pense, qu’il faut creuser un peu plus, car j’ai peut-être tout simplement cassé le voyant du tableau de bord pour ignorer le problème.
Oui et même ce code empêche la suppression des liens obsolètes dans wotb (car il n’existe que deux opérations pour op : CREATE et UPDATE, donc là le code wotb.removeLink devient mort), et donc introduit un nouveau bug de règle de distance lâche.
Sur la sortie standard elles y sont, mais pas dans le fichier de logs (encore un bug).
Dans ce cas, il faut créer IDX_DELETE et l’assigner à certification.op lorsque la certifciation doit expirer.
Pourtant le renvoi de port est bien configuré. Aaah satanée freebox.
Cette opération n’existe pas, le protocole est agnostique de toute suppression de donnée car il n’est aucunement nécessaire d’en avoir une pour que celui-ci fonctionne.
Je vais donner ce midi la solution que j’ai trouvée, si j’ai le temps.
edit : pas eu le temps 
mais le test avec verrou reproduisant le problème est codé. Je le nettoie ce soir puis je publie.
3 Likes
La version 1.7.18 a été buildée.
Je vais resynchroniser mon nœud sur g1-test.duniter.org, je vous invite ensuite à synchroniser sur le mien une fois l’accélération temporelle passée.
edit : done, par contre nous étions 6 issuers, donc mon nœud est bloqué s’il reste tout seul
2 Likes
J’ai fait la mise a jours et viens de lancer une sync basée sur g1-test.cgeek.fr, dés qu’elle sera finie nom nœud devrait calculer de nouveau
EDIT : ça y ai j’ai calculé un bloc. Ceux qui veulent peuvent se sync sur mon noeud : ts.gt.librelois.fr (port 443)
1 Like
Je suis aussi rentré dans la course. C’est reparti.
2 Likes
La monnaie a rattrapé son retard.
Il y a des nœuds qui ont décroché :
silkaj -gt diffi
Current block: n°364367, generated on the 2019-05-03 09:12:26
Generation of next block n°364368 possible by at least 2/2 members
Common Proof-of-Work difficulty level: 59, hash starting with `000[0-4]*`
| uid | match | Π diffi | Σ diffi |
|-----------+-----------+------------+-----------|
| jyt | 000[0-3]* | 4.9 × 10^4 | 60 |
| moul-test | 000[0-5]* | 4.1 × 10^4 | 58 |
silkaj -gt blocks
Last 11 blocks from n°364357 to n°364367
| block | gentime | mediantime | hash | uid |
|---------+---------------------+---------------------+------------+-----------|
| 364367 | 2019-05-03 09:12:26 | 2019-05-03 08:23:30 | 0000EF3EDD | jyt |
| 364366 | 2019-05-03 09:07:30 | 2019-05-03 08:19:10 | 0003599668 | moul-test |
| 364365 | 2019-05-03 09:07:20 | 2019-05-03 08:14:41 | 00005C4DED | jyt |
| 364364 | 2019-05-03 09:03:16 | 2019-05-03 08:10:10 | 0001F401CC | jyt |
| 364363 | 2019-05-03 09:00:58 | 2019-05-03 08:05:34 | 00010B24D0 | jyt |
| 364362 | 2019-05-03 08:59:58 | 2019-05-03 08:00:56 | 00010B62DA | jyt |
| 364361 | 2019-05-03 08:57:28 | 2019-05-03 07:56:25 | 00013681A7 | jyt |
| 364360 | 2019-05-03 08:56:51 | 2019-05-03 07:51:25 | 0001CD7535 | moul-test |
| 364359 | 2019-05-03 08:52:10 | 2019-05-03 07:46:24 | 0003E7A494 | moul-test |
| 364358 | 2019-05-03 08:40:22 | 2019-05-03 07:41:42 | 00008693FB | jyt |
| 364357 | 2019-05-03 08:40:17 | 2019-05-03 07:36:36 | 00014922E6 | jyt |
silkaj -gt blocks 500
Last 500 blocks from n°363868 to n°364367 from 3 issuers
| uid | blocks | percent |
|--------------+----------+-----------|
| moul-test | 342 | 68.4 |
| jyt | 146 | 29.2 |
| scanlegentil | 12 | 2.4 |
silkaj -gt blocks 1000
Last 1000 blocks from n°363368 to n°364367 from 5 issuers
| uid | blocks | percent |
|--------------+----------+-----------|
| moul-test | 645 | 64.5 |
| cgeek | 184 | 18.4 |
| jyt | 146 | 14.6 |
| Elois | 13 | 1.3 |
| scanlegentil | 12 | 1.2 |
En fait, cgeek a forké tout seul dans son coin. Donc, il y a deux monnaies de test plus réconciliables.