Xxhash: Une taille de morceau inégale dans le flux xxh3 calcule un hachage incorrect

Créé le 28 mai 2020 · 7Commentaires · Source: Cyan4973/xxHash

J'ai remarqué une différence dans le calcul d'un hachage xxh3 (et xxh128) lorsque les morceaux de données sont de taille inégale. Je teste xxh3 pour une éventuelle inclusion dans rsync (une fois qu'il se stabilise), et lorsque la compression de transfert est utilisée, la taille des morceaux du côté réception peut varier énormément, ce qui entraîne une erreur dans la somme de contrôle du fichier.

J'ai créé un cas de test simple pendant que je diagnostiquais le problème, mais il ne semble pas vraiment dépendre des données (bien que j'en ai fourni quelques-unes dans le cas de test) mais des tailles de morceaux étranges. Exécutez simplement "make" et il compilera le programme C simple et traitera les 2 fichiers de test (un avec des morceaux pairs et un avec des morceaux inégaux).

streaming-bug.tar.gz

(Remarque : j'ai mis à jour le fichier tar pour éviter un appel de mise à jour supplémentaire de longueur 0 après chaque bloc. Les fichiers d'entrée ont une nouvelle ligne de fin ajoutée au texte de chaque bloc et tester.c ne le supprimait pas, ce qui a entraîné un bloc de 0 octet dû à la ligne vide. Cela n'a pas affecté le résultat final, mais c'est plus propre avec le changement.)

bug

Source

WayneD

👀1 👍1

Tous les 7 commentaires

Je confirme que je peux reproduire le problème avec le code source lié.

Les raisons de l'erreur ne sont toujours pas claires.
Un autre test, qui ingère des données dans des segments de longueur aléatoire, semble fonctionner correctement jusqu'à présent, en utilisant exactement la même API.
L'enquête est en cours.

Cyan4973 le 29 mai 2020

Hmmmmmmm, il y a certainement plus de choses qui clochent ici.

Si j'ajoute également la fonction single shot, j'obtiens un troisième résultat.

./tester normal-chunks uneven-chunks

normal-chunks
incr:   cf3093cedd619ac9
full:   cf3093cedd619ac9
single: 8ef77a435d6e1fa9

uneven-chunks
incr:   ba74115927b80788
full:   cf3093cedd619ac9
single: 8ef77a435d6e1fa9

Mais si je remplace tout par les fonctions XXH64 équivalentes, elles renvoient toutes le même résultat.

./tester normal-chunks uneven-chunks
                                                                                   normal-chunks
incr:   98a65b63b84f8277
full:   98a65b63b84f8277
single: 98a65b63b84f8277

uneven-chunks
incr:   98a65b63b84f8277
full:   98a65b63b84f8277
single: 98a65b63b84f8277

easyaspi314 le 29 mai 2020

👍1

OK, je pense avoir compris.
Il nécessite une séquence spécifique de tailles pour apparaître,
mais je suis néanmoins surpris que ce problème ne soit pas apparu lors des tests.
Quelque chose doit être amélioré là-bas.

Cyan4973 le 29 mai 2020

OK, corrigé.
En effet, c'était un bug assez méchant. Merci @WayneD pour l'avoir signalé !

Je dois maintenant penser à un moyen de déclencher ce bug pendant les tests, et l'intégrer dans le PR.

Cyan4973 le 29 mai 2020

Bon travail! Je suis content qu'il n'ait pas été trop difficile de le réparer. Je suppose que je viens d'avoir de la "chance" avec une combinaison de tests rsync de xxh128 checksums + un test de compression, puis je me suis retrouvé avec un échec reproductible (puis j'ai juste demandé à rsync d'écrire la séquence d'appels de checksum qui échouait dans un format de fichier simple).

J'ai vérifié que votre branche "fix378" fonctionnait correctement dans mon test rsync qui échouait.

WayneD le 29 mai 2020

👍1

Maintenant, j'ai juste besoin de comprendre pourquoi rsync calcule une valeur de somme de contrôle différente pour environ 1/4 des fichiers copiés que je viens de copier par rapport aux sorties xxh128 (où aucun problème de ce type ne se produit lors de la comparaison des valeurs xxh64).

WayneD le 29 mai 2020

Les choses s'accordent correctement maintenant. Je pense que j'avais seulement re-lié mon code initialement et j'ai dû le recompiler pour qu'il soit complètement corrigé.

WayneD le 29 mai 2020

👍1

Cette page vous a été utile?

0 / 5 - 0 notes