systemtap

Hi folks! My stap scripts keeps failing either with a "user string copy fault" or with a "read fault". Is there a way get more context information about the error? A stacktrace for example? :) Thanks! Cheers, Alex

Update sendmmsg syscall test.

Update sendmmsg syscall test.

https://sourceware.org/bugzilla/show_bug.cgi?id=20363 Bug ID: 20363 Summary: syscall return probes should provide a richer retstr Product: systemtap Version: unspecified Status: NEW ... [More] Severity: enhancement Priority: P2 Component: tapsets Assignee: systemtap at sourceware dot org Reporter: jistone at redhat dot com Target Milestone: --- The result of most system calls is just a simple return value, and our tapset-provided retstr=return_str(...) is sufficient. Some system calls have additional data to return, and it would be nice to have a uniform way to show this too. A sys_read will have written some data in the buffer, a sys_ptrace may have extra data depending on the sort of PTRACE_FOO request, etc. And these only apply when the primary return value was not an error. It would be nice if this were added to ALL syscalls, even if they have nothing extra to show, so one could write something like: [Less]

Merge branch 'fche/pr18079'

Hi ! Not sure, if this is a developer list or something I can ask about some unexpected behavior of Systemtap. I am using Systemtap 2.6/0.159 on debian 8.5 with kernel 3.16.0-4. My script does not produce any errors, but it definitively does not ... [More] catch all packets! The core is just this: probe udp.sendmsg { if ( dport == 53 ) { printf ("PID %5d (%s) sent UDP to %15s 53\n", pid(), execname(), daddr) } } This should provide me with all processes which make DNS calls (per UDP). This is similar to examples on the examples site. What I see are packets bei user applications like iceweasel and thought, everything ok. Wrong. Then I took nslookup and it's call was NOT to see. I fired up a tcpdump for dst port 53 and this show the nslookup's outgoing call. There is plenty of memory free (usually about 8 GB) und loadavg is below 0.5 Additionally, outgoing calls from LXC containers are not seen - but they dont use remote tunneled ports, they use the local bridges. tcpdump shows these packets too. It not ea [Less]

Tweak autocast-defined interactions further

Tweak autocast-defined interactions further

https://sourceware.org/bugzilla/show_bug.cgi?id=20341 Bug ID: 20341 Summary: optimizer does not remove variables that are read in probe aliases but not end-user probes Product: systemtap ... [More] Version: unspecified Status: NEW Severity: normal Priority: P2 Component: translator Assignee: systemtap at sourceware dot org Reporter: flu at redhat dot com Target Milestone: --- Sometimes a string or integer must be constructed through accumulation in a tapset: result = "" result2 = 0 while (condition) { result .= "str" result += 1 } If this accumulation were to be done in a probe alias, the compiler marks these variables as being read even though consumer of the probe alias may not have used these variables. probe alias = begin { read = "TEST" unused = "1" unused = unused . "2" } $ stap -p2 -e 'probe alias {print(read)}' begin /* <- alias = begin <- alias */ # locals read:string [Less]

Update aux_syscalls.stp for android 3.0 kernels.