diff options
author | Petr Machata <pmachata@redhat.com> | 2014-05-06 12:23:54 +0200 |
---|---|---|
committer | Chanho Park <chanho61.park@samsung.com> | 2014-08-22 20:38:25 +0900 |
commit | 70c93e2e194b81dcafbeecb537f6915253791690 (patch) | |
tree | 87142bbbd5c9b3b18e2e867682963282ba5bf2f9 | |
parent | 6e7de13ac928f0928b03f8bf4d533936692e743a (diff) | |
download | ltrace-70c93e2e194b81dcafbeecb537f6915253791690.tar.gz ltrace-70c93e2e194b81dcafbeecb537f6915253791690.tar.bz2 ltrace-70c93e2e194b81dcafbeecb537f6915253791690.zip |
Add a couple TODO items
-rw-r--r-- | TODO | 30 |
1 files changed, 30 insertions, 0 deletions
@@ -193,3 +193,33 @@ * BUGS ** After a clone(), syscalls may be seen as sysrets in s390 (see trace.c:syscall_p()) +** leak in regex matching + >> I looked into this. Ltrace is definitely leaking it. The regex is + >> released when filter_destroy() calls filter_rule_destroy(), but those + >> are not called by anything. + > + >Ah, there we go. I just saw that we call regfree, but didn't check + >whether we actually call those. Will you roll this into your change + >set, or should I look into it? + + I'd rather you looked at it, if you don't mind. + +** unconditional follow of pthread_create + + Basically we'd like to follow pthread_create always, and fork only if -f + is given. ltrace now follows nothing, unless -f is given, and then it + follows everything. (Really it follows everything alway and detaches + from newly-created children unless -f is given.) + + The thing is, in Linux, we can choose to follow only {v,}forks by + setting PTRACE_O_TRACE{V,}FORK. We can also choose to follow all clones + by setting PTRACE_O_TRACECLONE, but that captures pthread_create as well + as fork (as all these are built on top of the underlying clone system + call), as well as direct clone calls. + + So what would make sense would be to tweak the current logic to only + detach if what happened was an actual fork, which we can tell from the + parameters of the system call. That might provide a more useful user + experience. Tracing only a single thread is problematic anyway, because + _all_ the threads will hit the breakpoints that ltrace sets anyway, so + pre-emptively tracing all threads is what you generally need. |