| 2007-04-05 01:49:50 |
Andrew Bennetts |
bug |
|
|
added bug |
| 2007-04-05 01:51:18 |
Andrew Bennetts |
bug |
|
|
added attachment 'sigstop-demo.py' (sigstop-demo.py) |
| 2007-04-09 20:01:13 |
Micah Cowan |
strace: status |
Unconfirmed |
Rejected |
|
| 2007-04-09 20:01:13 |
Micah Cowan |
strace: statusexplanation |
|
This doesn't seem to be a bug. From strace(1), -f option:
If the parent process decides to wait(2) for a child
that is currently being traced, it is suspended
until an appropriate child process either terminates
or incurs a signal that would cause it to terminate
(as determined from the child’s current signal dis‐
position).
of course, if that child happens to be strace itself, the "until" bit probably ceases to apply.
I'm guessing the call to proc.communicate() involves wait()ing.
(Closing bug for now; if further information arises that suggests that this may still be a bug, please feel free to reopen.) |
|
| 2007-04-15 16:17:26 |
Andrew Bennetts |
strace: status |
Rejected |
Unconfirmed |
|
| 2007-04-15 16:17:26 |
Andrew Bennetts |
strace: statusexplanation |
This doesn't seem to be a bug. From strace(1), -f option:
If the parent process decides to wait(2) for a child
that is currently being traced, it is suspended
until an appropriate child process either terminates
or incurs a signal that would cause it to terminate
(as determined from the child’s current signal dis‐
position).
of course, if that child happens to be strace itself, the "until" bit probably ceases to apply.
I'm guessing the call to proc.communicate() involves wait()ing.
(Closing bug for now; if further information arises that suggests that this may still be a bug, please feel free to reopen.) |
You are correct that proc.communicate() invokes wait(), or rather waitpid(), but "proc" here is the strace process itself, which is not being traced, so should be irrelevant.
Perhaps I'm missing something, but I don't think that part of the man page applies to this case: there's no *child* being traced that is being wait()ed for. All there is is a thread, and the parent never wait()s or joins it while strace is running, so the part of the man page you quote doesn't seem to be relevant.
Regardless, the current behaviour seems to make it impossible for a program to reliably call strace -f on itself, which I think is a desirable thing to support. For debugging purposes, being able to wrap a function call with something that starts & stops strace would be quite handy.
I hope you don't mind me putting the status back to Unconfirmed for the moment. |
|
| 2007-05-16 22:36:03 |
Micah Cowan |
bug |
|
|
assigned to strace (Debian) |
| 2007-05-18 01:14:43 |
Micah Cowan |
strace: status |
Unconfirmed |
Confirmed |
|
| 2007-05-18 01:14:43 |
Micah Cowan |
strace: importance |
Undecided |
Medium |
|
| 2007-05-18 01:14:43 |
Micah Cowan |
strace: statusexplanation |
You are correct that proc.communicate() invokes wait(), or rather waitpid(), but "proc" here is the strace process itself, which is not being traced, so should be irrelevant.
Perhaps I'm missing something, but I don't think that part of the man page applies to this case: there's no *child* being traced that is being wait()ed for. All there is is a thread, and the parent never wait()s or joins it while strace is running, so the part of the man page you quote doesn't seem to be relevant.
Regardless, the current behaviour seems to make it impossible for a program to reliably call strace -f on itself, which I think is a desirable thing to support. For debugging purposes, being able to wrap a function call with something that starts & stops strace would be quite handy.
I hope you don't mind me putting the status back to Unconfirmed for the moment. |
|
|
| 2007-05-19 06:57:15 |
Bug Watch Updater |
strace: status |
Unknown |
Unconfirmed |
|
| 2010-11-11 21:02:44 |
Micah Cowan |
removed subscriber Micah Cowan |
|
|
|
| 2010-11-23 04:53:19 |
Andrew Bennetts |
strace (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2019-10-25 07:09:57 |
Vincent Ladeuil |
removed subscriber Vincent Ladeuil |
|
|
|
