gmane.linux.systemtap

[Bug translator/6871] New: uprobes $context values often wrong

fche at redhat dot com — 2008-09-06T14:51:53

It is unclear whether a translator or dwarf or uprobes problem is responsible, but many user-space probes that extract $context variables and up with incorrect values. bug #6851 is only one example; it's easy to see with probes like probe process("....").function("*").call {log($$parms)}

new systemtap snapshot available

2008-09-06T14:27:07

A new automated systemtap source snapshot is available ftp://sources.redhat.com/pub/systemtap/snapshots/systemtap-20080906.tar.bz2 958869 bytes, cec7293bd301b4737da7abe8d1b70b9689fd3f00 tag See also ftp://sources.redhat.com/pub/systemtap/snapshots/

Re: [PATCH 1/2] marker probe: $name support (Re: [RFC] sample test script and tapset for markers)

Masami Hiramatsu — 2008-09-05T23:25:44

Hi Frank, Frank Ch. Eigler wrote: OK, so here is the updated patch, which also includes stapprobes.5 update :-) Thank you,

Re: regression on global statistic variable

Stan Cox — 2008-09-05T19:14:43

Thanks, I totally missed that. I will have a fix shortly: (Display written but unread statistic "scalars").

Re: help with running systemtap

Frank Ch. Eigler — 2008-09-05T18:37:16

p v yahoo.com> writes: The confusion here is that fedora includes a fully separate "debug" variant of the kernel that enables lockdep and other functions, whereas systemtap needs the "-debuginfo" associated with any particular kernel variant. So, install "kernel-debug-debuginfo" and "kernel-debug-devel". One reason for this is that there is no convenient RPM syntax for systemtap to declare a dependency upon a matching pair of kernel-*-debuginfo and kernel-*-devel. A number of organizations are using it in that capacity. Most of them carefully test their scripts first on a development machine. The nature of our failures is that things rarely fail on the former if they worked on the latter. - FChE

[PATCH 3/3] utrace-probe: testcases for $argN and $return support on utrace-syscall probe

Masami Hiramatsu — 2008-09-05T16:53:53

Hi, Here is the patch which adds testcases for accessing $argN/$return from process.syscall. Thank you,

[PATCH 2/3] utrace-probe: add $return variable support on utrace-syscall-return probe

Masami Hiramatsu — 2008-09-05T16:53:51

Hi This patch allows you to get syscall return value from process.syscall.return probes. This just uses _stp_user_syscall_return_value() function declared in syscall.h. Thank you,

[PATCH 1/3] utrace-probe: add $argN variable support on utrace-syscall probe

Masami Hiramatsu — 2008-09-05T16:53:48

Hi This patch allows you to get syscall arguments from process.syscall probes. This just uses _stp_user_syscall_arg() function declared in syscall.h. Thank you,

Re: [PATCH 1/2] marker probe: $name support (Re: [RFC] sample test script and tapset for markers)

Frank Ch. Eigler — 2008-09-05T16:13:22

Hi - On Fri, Sep 05, 2008 at 12:04:43PM -0400, Masami Hiramatsu wrote: It's not a big difference, just that we tend to keep such data in the context. I mostly don't like the new struct being passed by void-* and then suffering unprotected dereference in the embedded-c functions. (Extra memory consumption is negligible - one more word per CPU. Initialization time/space could be further reduced if per-probe-point-type data were gathered into unions.) - FChE

Re: [PATCH 1/2] marker probe: $name support (Re: [RFC] sample test script and tapset for markers)

Masami Hiramatsu — 2008-09-05T16:04:43

I think adding those fields increases the overhead of cleanup/initialize and memory usage. So I decided to introduce new structure for that. Could you tell me what the advantage of those separated fields is?

help with running systemtap

p v — 2008-09-05T16:30:42

Hello, I've read most of the FAQ's on the web (and more) but I still can't figure out what's wrong with my setup. I've installed fresh FC9 on top of which I did install a debug kernel rpm. But stap is still unhappy and returning the "semantic error: libdwfl failure". Stracing it it shows that it's looking for the debug version of the vmlinux. The debug kernel package does have it but it's compressed - "vmlinuz" and puts this compressed version under /boot. What other steps do I need to perform in order to get stap working? Do I need additional packages (I am sorry don't have the output of strace on hand with me right now but if requested I'll post it). Simply what I am asking is - what are the steps needed to be able to run stap after installing fresh FC9. It's surprising that stap packages are installed although they are useless without some additional steps. Is there any other linux distribution which would have stap running out of the box? Also how stable is stap? Is it stable enough to be run on production machines? I apologize if this is the wrong forum for these questions in which case plese can you send me a pointer to the right forum? thx --pv pvlogin< at >yahoo.com

[PATCH 2/2] marker probe: add $name testcases

Masami Hiramatsu — 2008-09-05T15:34:01

Hi, Masami Hiramatsu wrote: Here is a patch of the testcases for $name support.

[PATCH 1/2] marker probe: $name support (Re: [RFC] sample test script and tapset for markers)

Masami Hiramatsu — 2008-09-05T15:32:24

Hi, Frank Ch. Eigler wrote: Here is a patch which add $name variable access from marker probe. I added _stp_mark_context structure which contains .name and .format strings for passing both of them to marker handler. Now you can get both of $format and $name from marker probes. Thank you,

Re: [PATCH 1/2] marker probe: $name support (Re: [RFC] sample test script and tapset for markers)

Frank Ch. Eigler — 2008-09-05T15:44:26

Hi - On Fri, Sep 05, 2008 at 11:32:24AM -0400, Masami Hiramatsu wrote: That seems unnecessary. You could have added the name/format as separate fields, and have the embedded-C functions use CONTEXT->marker_name / marker_format. (Those fields then better be cleared to zero for other types of probes, and the embedded-C code better check for that.) - FChE

[PATCH 2/2] ia64: fast syscall args fetching in utrace probe

Masami Hiramatsu — 2008-09-05T15:23:44

Hi, Here is a patch which add fast syscall args fetching by using unwaddr cache in a utrace handler on ia64. Since syscall args can not be retrieved directly from pt_regs, we need to unwind the register stack. This patch speeds the unwinding up by caching unwound address in a probe handler (as same as __ia64_fetch_register()). Thank you,

[PATCH 1/2] ia64: add utrace support on ia64

Masami Hiramatsu — 2008-09-05T15:23:42

Hi, Here is a patch which add utrace on ia64 support to systemtap. I just checked it on rhel5.2 kernel (this means old utrace interface). Thank you,

Re: [PATCH] Fix redundant implicit probe points in listing mode.

Frank Ch. Eigler — 2008-09-05T13:27:32

Right. That's not too bad, though perhaps a session flag for global_var_display per se could be used instead. (It'd default to "on"; not have any command line option to disable it directly yet; but "-l"/'-L" would clear it.) This one can't go in. Instead, the tapset that includes that begin(-1) probe could be changed to do the initialization in a function (with a private initted-already? flag) rather than the begin probe. Future listings based on PR 3498 should make that workaround unnecessary. - FChE

[PATCH] Fix redundant implicit probe points in listing mode.

Wenji Huang — 2008-09-05T08:17:19

Hi, There are redundant probe points those will be outputted in listing mode. Such as: [wjhuang< at >systemtap]$ stap -l signal.d* signal.do_action begin(-1) end idx0:long This will just happen when functions calling included in definition of probe alias. There are initialization works done on implicitly begin(-1). And some operations on global variables are also processed on implicit end one. Those could enlarge the retrieved s.probes. There is workaround to solve it. [PATCH 1/1] Fix redundant implicit probe points in listing mode. --- elaborate.cxx | 2 ++ main.cxx | 3 ++- 2 files changed, 4 insertions(+), 1 deletions(-) diff --git a/elaborate.cxx b/elaborate.cxx index 44b6e24..7014928 100644 --- a/elaborate.cxx +++ b/elaborate.cxx < at >< at > -1148,6 +1148,8 < at >< at > semantic_pass_symbols (systemtap_session& s) void add_global_var_display (systemtap_session& s) { varuse_collecting_visitor vut; + + if (s.listing_mode) return; for (unsigned i=0; ibody->visit (& vut); diff --git a/main.cxx b/main.cxx index 83afb91..74fba86 100644 --- a/main.cxx +++ b/main.cxx < at >< at > -173,7 +173,8 < at >< at > printscript(systemtap_session& s, ostream& o) second->locations[0]->print(tmps); // XXX: [0] is less arbitrary here, but still ... } string pp = tmps.str(); - + if (!pp.compare("begin(-1)")) continue; + // Now duplicate-eliminate. An alias may have expanded to // several actual derived probe points, but we only want to // print the alias head name once. Regards, Wenji

regression on global statistic variable

Wenji Huang — 2008-09-05T01:49:52

Hi, There is regression on global statistic variable since commit "Display written but unread global statistics.". It will result in buildok/stat_insert.stp failing. SystemTap translator/driver (version 0.7.1/0.131 git branch stats, commit e491a713) Copyright (C) 2005-2008 Red Hat, Inc. and others This is free software; see the source for copying conditions. Session arch: x86_64 release: 2.6.27-rc5 Created temporary directory "/tmp/stap3SEvAs" Searched '/usr/local/share/systemtap/tapset/x86_64/*.stp', found 2 Searched '/usr/local/share/systemtap/tapset/*.stp', found 42 Pass 1: parsed user script and 44 library script(s) in 500usr/50sys/549real ms. WARNING: read-only local variable 'x' (alternatives: i j y loggy logmap liney linemap numbers strings): identifier 'x' at testsuite/buildok/stat_insert.stp:28:54 WARNING: read-only local variable 'y' (alternatives: i j x loggy logmap liney linemap numbers strings): identifier 'y' at :28:59 WARNING: eliding unused variable 'y': identifier 'y' at :19:33 semantic error: probe_1386 with type mismatch (long vs. stats): identifier 'loggy' at :5:8 semantic error: probe_1390 with type mismatch (long vs. stats): identifier 'liney' at :7:8 Pass 2: analyzed script: 5 probe(s), 2 function(s), 0 embed(s), 6 global(s) in 10usr/10sys/17real ms. Pass 2: analysis failed. Try again with more '-v' (verbose) options. Running rm -rf /tmp/stap3SEvAs Regards, Wenji

Re: [RFC PATCH 1/2] Bug Translator 3016 : Error accessing members of anonymous structs / unions

Masami Hiramatsu — 2008-09-04T19:13:25

Finally, I got a clue, here is a part of gdb log. ---- Starting program: /usr/bin/stap -e 'probe module("libsas").function("sas_ex_revalidate_domain"){print($port_dev->ex_dev->children)}' -vp2 Breakpoint 1 at 0x2ac797678930: file tapsets.cxx, line 2164. Breakpoint 2 at 0x2ac79766e640: file tapsets.cxx, line 2002. [Thread debugging using libthread_db enabled] Pass 1: parsed user script and 45 library script(s) in 260usr/20sys/275real ms. [New Thread 47036754412368 (LWP 4726)] [Switching to Thread 47036754412368 (LWP 4726)] Breakpoint 1, dwflpp::literal_stmt_for_local (this=0x2ac79a09c3d0, scope_die=0x2ac7a2757778, pc=123498677, local=< at >0x7fff13502350, components=< at >0x2ac7a2757c68, lvalue=false, ty=< at >0x2ac7a3062198) at tapsets.cxx:2164 2164 exp_type & ty) (gdb) c Continuing. Breakpoint 2, dwflpp::translate_final_fetch_or_store (this=0x2ac79a09c3d0, pool=0x7fff13501c90, tail=0x7fff13501d98, module_bias=0, die=0x7fff135017f0, attr_mem=0x7fff13501d30, lvalue=false, ty=< at >0x2ac7a3062198) at tapsets.cxx:2002 2002 exp_type & ty) (gdb) p *die $13 = {addr = 0x2ac7a2f13adf, cu = 0x2ac7a2745e00, abbrev = 0x2ac7a2751088, padding__ = 0} (gdb) p *die->cu $14 = {dbg = 0x2ac7a2745ae0, start = 312246, end = 380691, address_size = 8 '\b', offset_size = 4 '\004', version = 2, abbrev_hash = { size = 167, filled = 120, table = 0x2ac7a2753580}, orig_abbrev_offset = 6545, last_abbrev_offset = 8087, lines = 0x2ac7a3048028, files = 0x2ac7a27568a8, locs = 0x2ac7a3062200} ----- Actually, this die->cu was broken when stap got a SEGV. It's address(die->cu) is "0x7fff135017f0" + 8 ----- (gdb) watch die->cu Watchpoint 3: die->cu (gdb) c Continuing. Watchpoint 3: die->cu Old value = (struct Dwarf_CU *) 0x2ac7a2745e00 New value = (struct Dwarf_CU *) 0x5ea1e000001f4600 0x00002ac797aecb9a in __libdw_formref (attr=0x7fff13501d30, return_offset=0x7fff13501818) at elfutils-0.137/libdw/dwarf_formref.c:62 62elfutils-0.137/libdw/dwarf_formref.c: No such file or directory. in elfutils-0.137/libdw/dwarf_formref.c Current language: auto; currently c ---- Here, die->cu was overwritten. ---- (gdb) l 57in elfutils-0.137/libdw/dwarf_formref.c (gdb) disassemble Dump of assembler code for function __libdw_formref: 0x00002ac797aecb80 <__libdw_formref+0>:push %rbx 0x00002ac797aecb81 <__libdw_formref+1>:mov %rsi,%rbx 0x00002ac797aecb84 <__libdw_formref+4>:sub $0x10,%rsp 0x00002ac797aecb88 <__libdw_formref+8>:mov 0x8(%rdi),%rcx 0x00002ac797aecb8c <__libdw_formref+12>:mov %fs:0x28,%rax 0x00002ac797aecb95 <__libdw_formref+21>:mov %rax,0x8(%rsp) 0x00002ac797aecb9a <__libdw_formref+26>:xor %eax,%eax ----- Curiously, the assembler code just push a value to stack, ----- (gdb) p $rsp $23 = (void *) 0x7fff135017f0 ----- You can see the current stack pointer is same as the address of 'die'. This means, the 'die' originally has been stored on the stack memory (as a local variable) and passed it back to caller, and caller reuse this stack. I think below code is a suspicious code. Since temp_die is just a local variable, I think secound &temp_die(6th argument) should be die_mem as same as original function. Thank you,

Re: [RFC PATCH 1/2] Bug Translator 3016 : Error accessing members of anonymous structs / unions

Frank Ch. Eigler — 2008-09-04T14:53:45

Right. The problem with this line of thought is that the user will see messages that he won't know what to do with. There should be no message on clog at all if the search succeeds down another branch. One can use exceptions in this context just fine. When you recurse, you can catch the exceptions, only to throw a new (or a saved old) one should the final search results come up empty. - FChE