Community
Participate
Working Groups
Reported by Mathieu Desnoyers (10:09:39 AM) Compudj: il manque donc dup*, exec (pour tracker les O_CLOEXEC), fork (copie de fd table), clone (copie ou bien même fd table selon CLONE_FILES), close (10:10:21 AM) Compudj: il manquerait aussi les syscalls associés aux directory fd je crois (10:10:30 AM) Compudj: mais moins utile que pour les file FD (10:10:39 AM) Compudj: et éventuellement les syscalls de création de sockets Missing: Dup* exec (O_CLOEXEC) clone and fork (copying the table) Directory syscalls Socket syscalls (known that it's missing.)
(10:15:50 AM) Compudj: TheMatthew: une précision sur le ticket: pour le cas de clone(flags&CLONE_FILES), c'est pas juste une copie de la fd table, mais bel et bien une fd table _partagée_ (10:16:15 AM) Compudj: e.g. les open/close/etc du parent et du child altèrent la même fd table (10:17:28 AM) Compudj: ah et il manque fcntl (cmd==F_DUPFD) qui est en fait un dup Missing: clone with CLONE_FILES copies (references) the FD table, so that means it is the same FD. also look up fcntl (cmd==F_DUPFD)
LTTng details. (11:17:09 AM) tahini: TheMatthew, les fds c'est per pid, right? donc si plusieurs threads d'un même process ouvrent des fichiers, alors les fds seront assignés pour le pid (11:19:09 AM) TheMatthew: Un thread a ses propres fds... e.g. chaque thread a stdin/out/err (11:20:46 AM) TheMatthew: Hmm par process, je ne suis pas certain. (11:21:11 AM) TheMatthew: Compudj: as an interested party, you may wish to read the above ^ (11:23:15 AM) tahini: dans l'événement lttng_statedump_file_descriptor, le champ pid réfère bien au pid? pas au tid? (11:25:17 AM) TheMatthew: https://bugs.eclipse.org/bugs/show_bug.cgi?id=553493 (11:26:26 AM) matthiasb_ left the room (quit: Ping timeout: 480 seconds). (11:33:47 AM) Compudj: tahini: je pense que c'est un bogue de lttng-modules en fait (11:33:49 AM) Compudj: pour un cas rare (11:34:04 AM) Compudj: typiquement, la fd table va être partagée entre les threads d'un process (11:34:16 AM) Compudj: si les threads sont créés avec le clone flag CLONE_FILES (11:34:21 AM) Compudj: (ce qui est habituel) (11:34:35 AM) Compudj: mais rien n'empêcherait de créer un thread à bras avec clone sans CLONE_FILES (11:35:12 AM) Compudj: je pense que cette subtilité explique pourquoi lsof liste les file descriptors de chaque thread, et non pas juste par process (11:35:18 AM) Compudj: même s'ils sont typiquement juste répétés (11:36:10 AM) Compudj: fixer ça dans lttng-modules impliquerait d'itérer sur chaque process/thread, et de dumper les fd pour chaque tid (11:38:09 AM) tahini: Compudj donc dans lttng c'est bien par process, avec la supposition que la table est partagée entre les threads (11:39:03 AM) Compudj: oui, ce qui est (rarement) possiblement faux (11:39:16 AM) Compudj: je vais ouvrir un ticket sur bugs à ce sujet (11:39:20 AM) tahini: Mais dans les analyses, il faudrait qu'on fasse des cas séparés pour le CLONE FILES et sans CLONE FILES (11:39:40 AM) tahini: au fait CLONE FILES c'est table de fd partagée ou pas? (11:39:49 AM) tahini: clone implique copie d'habitude (11:40:59 AM) tahini: donc je m'attendrais à une table copiée, mais qui évolue séparément avec CLONE FILES (11:42:24 AM) Compudj: https://bugs.lttng.org/issues/1245 (11:42:50 AM) Compudj: If CLONE_FILES is set, the calling process and the child process (11:42:53 AM) Compudj: share the same file descriptor table. (11:42:55 AM) Compudj: see clone(2) (11:43:42 AM) tahini: ok... mettons que ça clone la référence à la table fd (11:43:43 AM) Compudj: et oui, les analyses au niveau modèle devraient gérer le cas CLONE_FILES vs not CLONE_FILES différemment (11:44:46 AM) Compudj: CLONE_FILES est juste un flag.. sa sémantique dépend de la description de la man page ;) (11:51:59 AM) tahini: Compudj, de la façon que lttng-modules génère les syscalls, penses-tu que ce serait facile de transformer les champs flags en bit flag enums? (12:08:25 PM) Compudj: tahini: oui, il suffit d'implémenter un "override" pour ce syscall (12:08:36 PM) Compudj: ça override le behavior auto-généré (12:08:51 PM) Compudj: tahini: cependant, mjeanson est très actif dans ce bout de code (12:09:14 PM) Compudj: mais rien n'empêcherait de gérer les merge conflicts par la suite (12:12:41 PM) tahini: ok, je trippe peut-être un peu trop sur les enum flags, mais ça aide à lire une trace! (12:21:56 PM) Compudj: tahini: tu fais bien, c'est une énorme amélioration de usability (12:22:08 PM) Compudj: tahini: je suis très content que tu proposes ces changements (12:25:11 PM) Compudj: tahini: je vais regarder le bug 1245 à l'instant (12:25:21 PM) Compudj: à moins que tu sois dessus (12:26:27 PM) tahini: non, j'y suis pas, mon problème pour l'instant est plutôt de voir comment présenter l'info aux usagers (12:27:33 PM) tahini: lttng-analyses est une bonne inspiration, mais Trace Compass doit profiter de son interactivité
