Patch #1633 has been updated. Project: Category: None Status: Open Summary: Terminated with C-c rpctrace:d programs hang
Follow-Ups: Date: Mon 06/16/2003 at 14:55 By: ogi Comment: This patch is a possible resolution of bug #3939[1] [1] http://savannah.gnu.org/bugs/?func=detailbug&bug_id=3939&group_id=30 ------------------------------------------------------- Date: Sat 08/02/2003 at 23:51 By: marcus Comment: One question: Have you actually tested if it fixes the bug? If you have tested it, I am willing to commit it (unless some objections come from some other maintainer, which doesn't seem to be the case). ------------------------------------------------------- Date: Sun 08/03/2003 at 16:05 By: ogi Comment: Yes, after replacing proc with patched one, terminating traced program with C-c or kill behaves as expected. ------------------------------------------------------- Date: Sat 08/09/2003 at 18:47 By: marcus Comment: Thanks, I have applied the patch now. ------------------------------------------------------- Date: Sun 08/17/2003 at 00:22 By: marcus Comment: I have reverted the patch on Rolands request. The main issue is that proc sends a message to an untrusted port (the thread port provided by the user). Here is Roland's analysis of alternative approaches: rpctrace really ought to be wrapping the thread control ports as it does the task port. There is a thread_set_special_port that can do this in just the same way. The problem is that it is not aware of threads being created. I think the same problem exists with newly-created tasks. The task port from a task_create and the thread port from a thread_create get traced like other ports and so rpctrace sees the messages sent by the exec server and so forth. But once the new task does mach_task_self, it gets its own real port and rpctrace is out of the picture. rpctrace needs to grok task_create and thread_create reply messages specially and no only wrap those ports, but perform set_special_port on them. A kludge would be to grok those msgids and assume they are right. Another approach is to maintain for each traced port whether we think it is a task, a thread, or something else, and for send-once rights if they are the reply port for a task_create or thread_create or not. Starting out with the task port, you know it is a task. If a task gets a task_create message, the reply port is a task_create reply port; if a task gets a thread_create message, the reply port is a thread_create reply port. If one of those special reply port gets its corresponding reply message ID, the port therein is a task/thread port and rpctrace tweaks it. This plan won't catch task or thread ports that are passed in to a traced program and start tracing them, but that's probably not something you want anyway (e.g. if you are tracing proc, then you might not want tracing proc_dostop to make you start tracing that thread). rpctrace doesn't yet support "attach" anyway, but if it did then it would need to not just interpose on the live task port, but find all its threads and interpose on their thread ports individually. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://savannah.gnu.org/patch/?func=detailpatch&patch_id=1633&group_id=30 _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
