Pas d'idée à priori, mais si ça passe à tous les coups avec un strace, il y a des chances que ça soit lié à une race condition.
Genre le filesystem qui met du temps à valider un nouveau fichier (je ne vois pas pourquoi mais bon...) et qui du coup, en passant par le strace, tu es sur que l'opération et finie et que ton fichier est bien présent.
ça peut être nimporte quelle race condition du genre, en général c'est une notif qu'un boulot fait pas un autre process est fini (process se termine, pipe se ferme, ...), mais quand tu vas chercher le résultat trop vite derrière, il n'est pas encore là.
Je ne sais pas trop comment débuguer ce genre de chose à la ligne de commande, je tenterais vraiment des trucs au cas par cas.
Une dernière idée si tu veux tenter d'autres trucs, c'est de :
1) tenter de compiler une version debug de dpkg-deb et voir si tu as toujorus le crash
2) remplacer le lancement de dpkg-deb par un appel à "gdb --batch --args dpkg-deb $#" et n'oublie pas de placer un .gdbinit quelque part avec la commande run
quand le sous process va planter (s'il plante) tu auras le prompt gdb et tu pourras tenter de voir ce qu'il se passe.
C'est une solution qui demande un peu d'expérience, et qui a de fortes chance de ne pas marcher cas ça ne plantera pas depuis gdb.
Si c'est le cas et que la version debug crash quand même, tu peux tenter la solution (plus compliquée, et sur android je ne saurais pas comment faire perso) d'installer un crash handler qui va attacher à gdb le process qui plante une fois le crash survenu.
Voila, c'est vraiment si t'as envie de t'amuser tout ça....
[^] # Re: piste pour deboguer
Posté par moi1392 . En réponse au message Souci fonctionnement dpkg avec debian sur vieil android. Évalué à 3.
Pas d'idée à priori, mais si ça passe à tous les coups avec un strace, il y a des chances que ça soit lié à une race condition.
Genre le filesystem qui met du temps à valider un nouveau fichier (je ne vois pas pourquoi mais bon...) et qui du coup, en passant par le strace, tu es sur que l'opération et finie et que ton fichier est bien présent.
ça peut être nimporte quelle race condition du genre, en général c'est une notif qu'un boulot fait pas un autre process est fini (process se termine, pipe se ferme, ...), mais quand tu vas chercher le résultat trop vite derrière, il n'est pas encore là.
Je ne sais pas trop comment débuguer ce genre de chose à la ligne de commande, je tenterais vraiment des trucs au cas par cas.
Une dernière idée si tu veux tenter d'autres trucs, c'est de :
1) tenter de compiler une version debug de dpkg-deb et voir si tu as toujorus le crash
2) remplacer le lancement de dpkg-deb par un appel à "gdb --batch --args dpkg-deb $#" et n'oublie pas de placer un .gdbinit quelque part avec la commande run
quand le sous process va planter (s'il plante) tu auras le prompt gdb et tu pourras tenter de voir ce qu'il se passe.
C'est une solution qui demande un peu d'expérience, et qui a de fortes chance de ne pas marcher cas ça ne plantera pas depuis gdb.
Si c'est le cas et que la version debug crash quand même, tu peux tenter la solution (plus compliquée, et sur android je ne saurais pas comment faire perso) d'installer un crash handler qui va attacher à gdb le process qui plante une fois le crash survenu.
Voila, c'est vraiment si t'as envie de t'amuser tout ça....