Aller au contenu | Aller au menu | Aller à la recherche
dimanche 27 septembre 2009
Par eau le dimanche 27 septembre 2009, 00:12 - geeking
Eh ouiii, on m'a averti cette semaine GDB a une nouvelle super fonctionnalite conviviale qui permet de faire (grossierement) "marche-arriere" et donc et revenir a l'etat d'execution precedent et puis le precedent et puis le precedent en gros de runner le code a l'envers... voila c'est fait GDB fonctionne comme un magnetoscope VHS et ca se passe par ici.
jeudi 27 août 2009
Par poz le jeudi 27 août 2009, 14:40 - geeking
Je vais probablement enfoncer des portes ouvertes mais c'est pas grave. Récemment j'ai écouté le trafic d'une machine qui streamait du son via le protocole DAAP (le truc de iTunes) sous un linux (donc une approximation de DAAP en fait, car les specs ne sont pas releasées). Bref, le linux envoie de la musique sur un LAN via le soft rhythmbox. Ça passe par un LAN, et arrive au client. En faisant un coup de tcpdump sur le serveur, je m'aperçois que les datagrammes IP font régulièrement plus de 1500 bytes. Souvent 5 ou 7 KB. Curieux... Je me demande d'où ça vient. Qui plus est, le checksum TCP est incorrect. Vraiment chelou, ça.
$ ip link ls eth0
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:12:3f:71:57:a1 brd ff:ff:ff:ff:ff:ff
La MTU est bien à 1500. Si j'écoute sur le client, je vois bien des paquets fragmentés. Bizarre bizarre. Le switch ferait ça ? Je mirror les ports et j'écoute : paquets fragmentés. Boooon, après avoir cherché à droite à gauche, je tombe sur ces liens :
L'explication est que la fragmentation est réalisée par la carte réseau, hypothèse que j'avais exclue d'emblée, parce que ça me semblait overkill. Et pourtant ! Un patch avec des benches envoyés sur la ml netdev du noyau linux montre que ça améliore significativement les performances (dans le cas où le firmware permet de le faire, bien sûr), et ça semble intégré depuis le 2.6.18.
C'est tout. Je voulais juste poster ça pour éviter aux ignares comme moi de chercher pendant des plombes le pourquoi du comment. Enfin... encore faut-il qu'ils connaissent ce site. :-)
PS : pour le checksum erroné, c'est visiblement parce que la stack TCP/IP sait que le device va regragmenter, et donc invalider le checksum calculé (et en mettre un autre à la place). Donc pas la peine de se fatiguer à le calculer. C'est mon hypothèse, il faudrait que je regarde les sources.
mardi 26 février 2008
Par eau le mardi 26 février 2008, 13:33 - geeking
Prrrrt,
Je viens de decouvrir ce projet en lisant un forum convivial
Une suite de tools autour d'un editeur hexa avance, pour faire du disass, du tracing etc... il est meme capable de bosser sur du java bytecode et/ou des format PE.
Enfin voila marrant, je regarde et je teste pour le moment..
vendredi 14 septembre 2007
Par eau le vendredi 14 septembre 2007, 17:48 - geeking
Une petite doc classique de référence pour l'utilisation de gdb, avec lequel je refais connaissance :
http://www.hlrs.de/organization/amt/services/tools/debugger/gdb/doc/gdb-6.3.pdf
Suivi de la doc officielle : http://sourceware.org/gdb/current/onlinedocs/gdb_toc.html
Et des internals :
http://sourceware.org/gdb/current/onlinedocs/gdbint_toc.html
Au passage il y a des trucs "vieux" mais utiles aussi comme :
Et des nouveaux "types" de debuggers, faudrait regarder aussi par là :
