summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPetr Machata <pmachata@redhat.com>2014-05-06 12:23:54 +0200
committerChanho Park <chanho61.park@samsung.com>2014-08-22 20:38:25 +0900
commit70c93e2e194b81dcafbeecb537f6915253791690 (patch)
tree87142bbbd5c9b3b18e2e867682963282ba5bf2f9
parent6e7de13ac928f0928b03f8bf4d533936692e743a (diff)
downloadltrace-70c93e2e194b81dcafbeecb537f6915253791690.tar.gz
ltrace-70c93e2e194b81dcafbeecb537f6915253791690.tar.bz2
ltrace-70c93e2e194b81dcafbeecb537f6915253791690.zip
Add a couple TODO items
-rw-r--r--TODO30
1 files changed, 30 insertions, 0 deletions
diff --git a/TODO b/TODO
index 3ab6703..af1198c 100644
--- a/TODO
+++ b/TODO
@@ -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.