patchThe GNU Hurd - Patches: patch #1633, Terminated with C-c rpctrace:d...

 
 

You are not allowed to post comments on this tracker with your current authentification level.

patch #1633: Terminated with C-c rpctrace:d programs hang

Submitted by:  Ognyan Kulev <ogi>
Submitted on:  Mon 16 Jun 2003 12:53:06 PM UTC  
 
Category: NonePriority: 5 - Normal
Status: NonePrivacy: Public
Assigned to: Marcus Brinkmann <marcus>Open/Closed: Open
Planned Release: None
Wiki-like text discussion box: 

Sat 16 Aug 2003 10:22:29 PM UTC, comment #4:

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.

Marcus Brinkmann <marcus>
Project AdministratorIn charge of this item.
Sat 09 Aug 2003 04:47:50 PM UTC, comment #3:

Thanks, I have applied the patch now.

Marcus Brinkmann <marcus>
Project AdministratorIn charge of this item.
Sun 03 Aug 2003 02:05:18 PM UTC, comment #2:

Yes, after replacing proc with patched one, terminating traced program with C-c or kill behaves as expected.

Ognyan Kulev <ogi>
Project Member
Sat 02 Aug 2003 09:51:51 PM UTC, comment #1:

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).

Marcus Brinkmann <marcus>
Project AdministratorIn charge of this item.
Mon 16 Jun 2003 12:53:06 PM UTC, original submission:

This patch is a possible resolution of bug #3939[1]

[1] http://savannah.gnu.org/bugs/?func=detailbug&bug_id=3939&group_id=30

Ognyan Kulev <ogi>
Project Member

 

Attached Files
file #5818:  patch_item_1633.patch added by ogi (1015B - text/plain - patch item 1633)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 4 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Sat 16 Aug 2003 10:22:29 PM UTCmarcuspatch_status_id2=>
Sat 09 Aug 2003 04:47:50 PM UTCmarcuspatch_status_id1=>
  Assigned toNone=>NA
  Closed on-=>-

Back to the top


Powered by Savane 3.1-cleanup