Re: ERROR: ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)]

On Sat, Jun 10, 2023 at 10:10:15PM +, Bjoern A. Zeeb wrote: > Hi, > > compiling with gcc I see a lot of: > > ERROR: ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)] > > I wonder "Unsupported version" of what? and can we improve it? It's referring to the DWARF version.

Re: DTrace - capturing two userspace strack frames on top of system call

On Mon, Jan 23, 2023 at 04:54:05PM -0500, Martin Cracauer wrote: > Mark Johnston wrote on Mon, Jan 23, 2023 at 11:52:12AM -0500: > > On Sun, Jan 22, 2023 at 10:04:50PM -0500, Martin Cracauer wrote: > > > Actually the error only appears on arm64 for me. I moved the scr

Re: DTrace - capturing two userspace strack frames on top of system call

On Sun, Jan 22, 2023 at 10:04:50PM -0500, Martin Cracauer wrote: > Actually the error only appears on arm64 for me. I moved the script > to amd64 and it works as I thought. Support for userspace tracing on arm64 is definitely less mature than on amd64, so this isn't too surprising,

Re: In DTrace, why does timestamp increase after a call to chill() but vtimestamp and walltimestamp do not?

On Wed, Nov 23, 2022 at 09:07:23AM -0500, Mark Johnston wrote: > On Mon, Nov 21, 2022 at 06:19:16PM +0100, Mateusz Piotrowski wrote: > > Hello all, > > > > I'd like to understand why calling chill() in a DTrace action block > > increases the timestampv

Re: In DTrace, why does timestamp increase after a call to chill() but vtimestamp and walltimestamp do not?

On Mon, Nov 21, 2022 at 06:19:16PM +0100, Mateusz Piotrowski wrote: > Hello all, > > I'd like to understand why calling chill() in a DTrace action block increases > the timestampvariable, but not vtimestamp and walltimestamp. > Here's an example showing timestamp increasing after a call to

Re: Query about work with/on DTrace

On Thu, Nov 17, 2022 at 03:16:33PM +, Domagoj Stolfa wrote: > Hi: > > > I'm in the process of writing an article for the FreeBSD Journal > regarding DTrace and was hoping to get some submissions of what people > are working on in what would be called the "exciting new work" part of > the

Re: vminfo provider for FreeBSD

On Mon, Jun 13, 2022 at 04:43:53PM -0400, Peter Johnson wrote: > Cool. I will take a first stab at it and see how it goes. I presume the > preferred artifact is a patch against -CURRENT mailed to this list? That would be fine with me. freebsd-hackers@ would reach a wider audience though, so

Re: vminfo provider for FreeBSD

seful, > optimize the SDT implementation, address SMP or NUMA considerations, etc. > > Thoughts? This makes sense to me. The other thing we might consider is whether it's worth including additional arguments (e.g., the physical vm_page_t) in some cases. That could always be added later t

Re: vminfo provider for FreeBSD

On Thu, Jun 02, 2022 at 01:08:27PM -0400, Peter Johnson wrote: > Hi there -- > > I would find the probes in Illumos' vminfo provider [1] really handy to have > in FreeBSD and I'm happy to do the work to make it happen. The only > FreeBSD-related mention of the vminfo provider I can find is an

Re: DTrace, kernel loader, unknown probes, enable on load?

On Sat, Feb 12, 2022 at 12:16:45AM +, Bjoern A. Zeeb wrote: > On Fri, 11 Feb 2022, Mark Johnston wrote: > > > It appears to be sufficient to simply move the kld_load hook to before > > module registration, patch below. In the case of a subsequent error, > > the

Re: DTrace, kernel loader, unknown probes, enable on load?

On Fri, Feb 11, 2022 at 03:52:37PM +, Bjoern A. Zeeb wrote: > On Fri, 11 Feb 2022, Mark Johnston wrote: > > > On Fri, Feb 11, 2022 at 09:23:47AM -0500, Mark Johnston wrote: > >> On Fri, Feb 11, 2022 at 02:10:30PM +, Bjoern A. Zeeb wrote: > >>> Hi,

Re: DTrace, kernel loader, unknown probes, enable on load?

On Fri, Feb 11, 2022 at 02:10:30PM +, Bjoern A. Zeeb wrote: > Hi, > > one of the drawbacks of Dtrace (and other tracing frameworks out there > on various OSes) is that they do need a list of probes upfront before > they can enable. The probes don't have to exist, add -Z to the dtrace(1)

Re: dtrace: give %'d a chance?

On Thu, Nov 19, 2020 at 01:28:56PM +0200, Andriy Gapon wrote: > > what do people think about adding > setlocale(LC_NUMERIC, ""); > to dtrace's main function? That seems reasonable to me. > My primary interest is to (pretty-)print some numbers with a thousands > separator. > > Not sure if

Re: set argument

en by dtrace. Currently this is done by running ctfconvert on each object file, and by running ctfmerge on the output file (usually an executable or shared lib) of the build. If you're using FreeBSD's build infrastructure it should be sufficient to just set WITH_CTF=YES. > > On Mar 2, 2020, at 9:43

Re: set argument

On Mon, Mar 02, 2020 at 03:33:57PM +0530, Kamal R. Prasad wrote: > hello, > > How does dtrace access the argument type declarations when we define a new > SDT? eg:- I define an SDT that has arg0 as (struct mystrust*) > > I have defined in my proprietary header file > --- > typedef

Re: dtrace script matching lot of probes simply resets on i386

On Tue, Nov 05, 2019 at 11:23:28AM +, Bjoern A. Zeeb wrote: > Hi, > > I had an i386 kernel (amd64 machine) simply going to POST. After a lot > of “doh” I realised that it was a dtrace script which was matching a > lot of probes running as part of some automated stuff. > > The problematic

Re: Why my DTrace script does not work after installing a new kernel without reboot

On Sun, Oct 28, 2018 at 12:40:37AM +0200, Andreas Longwitz wrote: > I have a simple, probably stupid question. I run FreeBSD 10.4 Stable > r338093 and use the script > > #!/usr/sbin/dtrace -s > > dtrace:::BEGIN > { > printf("pf_default_rule.timeout[2/16/17]=%d/%d/%d\n", >

Re: dtrace -G vs. -flto

On Tue, Nov 28, 2017 at 01:34:00AM +0100, Jan Beich wrote: > I'd like to build www/firefox with both DTrace and LTO support. Both > Clang and GCC emit code that dtrace(1) doesn't understand. Unfortunately, both gcc and clang's LTO implementations are completely incompatible with the way that

Re: dtrace pid provider on entry == Trace/BPT trap process

On Tue, Nov 07, 2017 at 12:15:22PM +0100, Andreas Longwitz wrote: > Maybe the following is of interest for DTrace experts: > > >> I use FreeBSD 10.3-STABLE r317936 with updated /usr/lib/dtrace/ip.c and > >> see an issue that in my opinion should have been solved in r269342: > > > > 10.3 would be

Re: dtrace pid provider on entry == Trace/BPT trap process

On Tue, Sep 05, 2017 at 12:58:22PM +0200, Andreas Longwitz wrote: > I use FreeBSD 10.3-STABLE r317936 with updated /usr/lib/dtrace/ip.c and > see an issue that in my opinion should have been solved in r269342: 10.3 would be missing a number of other fixes for issues that might cause the symptom

Re: how to trace linux_open, linux_stat

On Tue, Aug 15, 2017 at 08:17:03PM +0300, Anatoly wrote: > Hello, I'm new to dtrace. I'm trying to run propiertary linux > application "1C thin client" (i386) using emulators/linux-c6 under > FreeBSD 11.1 amd64. Application starts, then stops shortly with error > message box and same error in log

Re: g_journal_read has broken argument list in V10

On Fri, Aug 04, 2017 at 12:46:18PM +0200, Andreas Longwitz wrote: > By the way, the following patch solves the problem with the wrong > argument counts in ctfdump: I think the existing code is correct. It's printing the CTF type index of the return type, not the number of arguments. In

Re: fbt:kernel:breadn_flags:entry): invalid address (0x0) in action #7

On Thu, May 18, 2017 at 10:45:34PM +0200, Domagoj Stolfa wrote: > Hello, > > > I suspect the easiest way here is just to check that your credential in > > args[6] is non-null in a predicate. > > yes, you would likely have to enable the probe twice -- once with a non-null > argument and once

Re: DTrace issues?

On Mon, Apr 17, 2017 at 09:28:07PM +0100, Sevan / Venture37 wrote: > On 17 April 2017 at 20:54, Ryan Stone wrote: > > On Sat, Apr 15, 2017 at 10:50 AM, George Neville-Neil > > > > wrote: > > > >> > >> Can you explain this grief? What is the problem? >

Re: RFC: Changes in DTrace to allow for distributed operation

On Fri, Dec 30, 2016 at 06:37:47PM +0100, Domagoj Stolfa wrote: > Hello, > > I have been working on extending DTrace to allow for a natural way of tracing > in > a distributed environment. This would consist of being able to trace events on > different virtual machines, remote servers with

Re: clause-local variable with copyin()

On Tue, Dec 20, 2016 at 03:02:24AM +0900, Hiroki Sato wrote: > Mark Johnston <ma...@freebsd.org> wrote > in <20161219030125.gb57...@wkstn-mjohnston.west.isilon.com>: > > ma> On Sat, Dec 17, 2016 at 03:10:14PM +0900, Hiroki Sato wrote: > ma> > Do I mis

Re: dtrace and kernel modules

On Thu, Jul 07, 2016 at 12:51:52PM +0800, Julian Elischer wrote: > I'm specifically interested in the case of kernel modules that > instantiate new syscalls. > > How much support do we have for that? In the one example in our > sources of a kld with a syscall (kgssapi.ko) dtrace seems to find

Re: Regarding Dtrace on Arm

On Wed, May 11, 2016 at 06:17:51PM +, Abhishek Kulkarni wrote: > Thanks very much Mark. Should I raise a bug about this on freebsd.org? That would be helpful, thanks. > > Regards > Abhishek Kulkarni > > > > > On 5/11/16, 9:49 AM, "Mark Johnston"

Re: Regarding Dtrace on Arm

On Sat, May 07, 2016 at 08:55:56PM +, Abhishek Kulkarni wrote: > Hello All, > > I was using Dtrace using the FBT provider on an arm platform with witness > enabled. When FBT is used with the kernel module, it generates a kernel panic > or the system becomes unresponsive. Is this problem

Re: CFT: replacement of cddl/contrib/opendtrace with the OpenDTrace version

On Wed, Apr 13, 2016 at 07:38:22PM -0700, George Neville-Neil wrote: > Howdy, > > I've created a new project and organization on githhub for maintaining > bits of DTrace, including the DTrace Toolkit. I have imported the last > known version of the toolkit into this repo: > >

Re: [patch] Fix crash on userland fbt tracing

On Mon, Apr 11, 2016 at 07:05:01PM +0900, Jihyun Yu wrote: > How to reproduce crash (tested on 10.3) > > - Run `top` on a shell > > - List dtrace probes with following command: > dtrace -p `pgrep top` -ln 'pid$target::clear:entry {} > pid$target::clear:return {}' > > - Try to attach probes

Re: I need a little help in fixing `exclusive sleep mutex urtwn0_com_lock` in CURRENT

On Fri, Apr 01, 2016 at 12:23:37AM +0300, Aleksander Alekseev wrote: > > > By any chance is it possible to trace mtx_lock / mtx_unlock calls > > > using DTrace? I see number of probes in `dtrace -l` which look like > > > something I need. Unfortunately they are named like knlist_mtx_lock > > > or

Re: I need a little help in fixing `exclusive sleep mutex urtwn0_com_lock` in CURRENT

On Thu, Mar 31, 2016 at 08:42:56PM +0300, Aleksander Alekseev wrote: > > So as I understand some code acquired a mutex and didn't release it. > > And naturally it has something to do with USB. Now how can I figure > > out what code acquired this lock? Best approach I can think of > > currently is

Re: Functions not getting picked up by dtrace

On Mon, Feb 29, 2016 at 02:07:45PM -0800, hiren panchasara wrote: > On 02/29/16 at 01:49P, hiren panchasara wrote: > > On 02/29/16 at 01:49P, Mark Johnston wrote: > > > On Mon, Feb 29, 2016 at 01:39:33PM -0800, hiren panchasara wrote: > > > > I've seen this earlie

Re: Functions not getting picked up by dtrace

On Mon, Feb 29, 2016 at 01:39:33PM -0800, hiren panchasara wrote: > I've seen this earlier with others too but this one is the latest > confusing me: em_xmit() in $src/dev/e1000/if_em.c > > Other functions with similar signature are listed in 'dtrace -l'. em_xmit() is a static function with a

Re: Running DTrace Userland probes at times terminates traced process

On Thu, Oct 15, 2015 at 10:53:00PM -0700, Shrikanth Kamath wrote: > It maybe a non issue but wanted to check with the forum, > > I am running the following dtrace one liner on the login process > > root@bsdvm#dtrace -ln 'pid$target::*:entry' -p > > root@bsdvm:~ # ps > PID TT STATTIME

Re: Regarding schedgraph.d

On Thu, Jul 02, 2015 at 07:40:21PM -0400, Ryan Stone wrote: The best that I can offer right now is the Illumos documentation: http://dtrace.org/guide/chp-sched.html I wrote and committed some DTrace provider man pages a little while ago. The page for the sched provider is here:

Re: regarding a query for the execsnoop script

On Fri, Jun 26, 2015 at 04:35:26PM -0700, abhishek kulkarni wrote: Hello All, I am trying to run the script execsnoop on FreeBSD. I need a patch for it that works for FreeBSD. Could you please provide me with one. The copy at cddl/contrib/dtracetoolkit/execsnoop works properly for me on

Re: Regarding a Sched Dtrace Script for FreeBSD

On Tue, Jun 16, 2015 at 11:01:27AM -0700, abhishek kulkarni wrote: Hello all, I am working on Dtrace and trying to implement a sched script for FreeBSD 10.0 The script uses the probes on-cpu and off-cpu. The purpose is to measure the time that a CPU spends on the current thread.

Re: removing USDT's libelf dependency

On Fri, Jan 30, 2015 at 10:15:09AM -0500, Ed Maste wrote: On 30 January 2015 at 01:13, Mark Johnston ma...@freebsd.org wrote: It turns out that GNU ld implements a similar feature, albeit in a more restrictive manner: a symbol named __start_id will have its value filled

Re: DTrace script to trace processes entering vfs::vop_remove

On Thu, Dec 04, 2014 at 12:55:40PM -0800, dte...@freebsd.org wrote: -Original Message- From: Mark Johnston [mailto:mark...@gmail.com] On Behalf Of 'Mark Johnston' Sent: Thursday, December 4, 2014 10:23 AM To: dte...@freebsd.org Cc: freebsd-dtrace@freebsd.org; 'Julian

Re: DTrace script to trace processes entering vfs::vop_remove

On Wed, Dec 03, 2014 at 03:19:31PM -0800, dte...@freebsd.org wrote: Hi markj, list, I wrote a script for $work to help me find out who on Earth keeps deleting files XYZ? from a particular storage server. Please find attached a copy of watch_vop_remove.d which has the following sample

Re: ufunc() doesn't work

On Wed, Oct 29, 2014 at 11:30:37PM +0500, Eugene M. Zheganin wrote: Hi. On 24.10.2014 23:54, Mark Johnston wrote: ufunc() is available in stable/10 as of r273595. I've just updated my system to r273822: [root@taiga:~]# uname -a FreeBSD taiga 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0

Re: ufunc() doesn't work

On Fri, Oct 24, 2014 at 10:33:32AM +0600, Eugene M. Zheganin wrote: Hi. I'm new to dtrace and I test various examples while learning, but it seems to me that I miss something. This example doesn't work on FreeBSD: dtrace -n 'profile-97/arg1/ { @[ufunc(arg1)] = count(); }' although it

Re: [dtrace-discuss] dtrace keywords in postfix expressions

, provider) now works), and the stringof keyword. If there aren't any objections I'll commit it to FreeBSD in a few days and submit a PR for illumos. Thanks, -Mark - Bryan On Fri, Oct 3, 2014 at 9:13 PM, Mark Johnston via dtrace-discuss dtrace-disc...@lists.dtrace.org wrote

dtrace keywords in postfix expressions

Hello, DTrace has a few keywords which are not keywords in C/C++ (e.g. provider). One annoyance which has come up a few times is the fact that such keywords cannot be used in expressions which would be valid in the code being traced. For example, FreeBSD's struct g_consumer contains a field

Re: [freebsd 9.2] dtrace causes hung process when called for strlen

On Thu, Sep 25, 2014 at 09:22:55PM -0700, madhava gaikwad via freebsd-dtrace wrote: Hello Experts, I am a freebsd newbie and having a strange issue on freebsd 9.2 (It is AMD64 machine).I am not able to dtrace few libc functions. For example I am able to dtrace strdup, but calling dtrace

Re: ZFS SET_ERROR dtrace probe possible under FreeBSD?

On Tue, Sep 16, 2014 at 11:05:09AM +0100, Steven Hartland wrote: - Original Message - From: Mark Johnston ma...@freebsd.org On Mon, Sep 15, 2014 at 07:59:50PM -0700, Matthew Ahrens wrote: Disclaimer: I'm not an expert in FreeBSD dtrace. It looks like the FreeBSD kernel

Re: ZFS SET_ERROR dtrace probe possible under FreeBSD?

On Mon, Sep 15, 2014 at 07:59:50PM -0700, Matthew Ahrens wrote: Disclaimer: I'm not an expert in FreeBSD dtrace. It looks like the FreeBSD kernel uses these declaration for kernel SDT probes, in sdt.h: 333 http://src.illumos.org/source/xref/freebsd-head/sys/sys/sdt.h#333#*define*

Re: Usage of DTRACE_PROBE macro from sdt.h in kernel modules

On Tue, Sep 02, 2014 at 01:24:47PM -0700, Shrikanth Kamath wrote: Adding a DTRACE_PROBE(name) in a kernel module does not create the SDT probe. I added the following to the module file before using DTRACE_PROBE. Somewhat confusingly, DTRACE_PROBE* shouldn't be used in the kernel. It's there

Re: dtrace pid provider on entry == segfault process

On Tue, Jul 29, 2014 at 7:10 PM, Adrian Chadd adr...@freebsd.org wrote: Ugh, that sent too quickly. Let me clarify: [root@darkwatch] /data/blockd# cat test2.d pid$target:libc*:memcpy:entry { @[execname] = quantize(arg2); } this doesn't work right (it doesn't count events at all) and it

Re: dtracing static symbols

On Wed, Mar 12, 2014 at 12:50 AM, Daniel O'Connor docon...@gsoft.com.au wrote: On 12 Mar 2014, at 15:15, Prashanth Kumar pra_ud...@yahoo.co.in wrote: If you run # env DTRACE_DEBUG=1 dtrace -Ppid\$target -l -c ./static you will notice that lot of probe creation will fail, also no probes are

Re: [patch] fasttrap process scratch space

be likely to cause problems? Hope that's helpful. It is, I appreciate the explanation. I didn't mean to imply that the solution used in Solaris is inferior to the approch I followed; I just felt that it's not so well-suited to FreeBSD. Thanks! -Mark Adam On Sun, Feb 23, 2014 at 8:14 PM, Mark

[patch] enable interrupts before calling fasttrap handlers

Hello, The patch here fixes a problem I've run into while doing some work on fasttrap: http://people.freebsd.org/~markj/patches/breakpoint_intr_enable.diff Specifically, we currently call fasttrap_pid_probe() with interrupts disabled because FreeBSD handles breakpoints through an interrupt gate

Re: your mail

On Tue, Nov 12, 2013 at 12:03:05PM +0800, Prashanth Kumar wrote: Hello, I had been doing some work on the pid provider in Dtrace. Hi Prashanth, I've been going through your patches and committing them as time permits. I have made a few modification  so that it will list all the

Re: dtrace showed matched probes but nothing in output on FreeBSD 9.1-RELEASE

On Tue, Nov 05, 2013 at 02:47:58PM +0800, John Luk wrote: Hi, Mark. The gdb output is included below. I'm wondering why dtrace -l can trace all my function correctly but the D script failed. Is it because they get the symbol table in different way? Hm, I can't reproduce the problem using

Re: dtrace showed matched probes but nothing in output on FreeBSD 9.1-RELEASE

On Sat, Nov 02, 2013 at 11:56:49AM +0800, John Luk wrote: Hi all, I'm a newbie in dtrace, and I following this tutorial from Oracle: http://docs.oracle.com/cd/E19205-01/820-4221/ to learn dtrace. In the example of test.c and ufunc.d, I expected output like this: % dtrace -s ufunc.d -c

Re: unstable sdt probes

On Tue, Oct 29, 2013 at 11:20:51PM +0200, Andriy Gapon wrote: on 26/10/2013 21:06 Mark Johnston said the following: The patch here is what I had in mind: http://people.freebsd.org/~markj/patches/zfs_probes.diff I've only compile-tested it, but it should create illumos-compatible ZFS

Re: Firefox crash during dtrace attach under -CURRENT

On Fri, Oct 25, 2013 at 11:47:06AM +0100, symbol...@gmx.com wrote: On Wed, Oct 23, 2013 at 10:59:02PM -0400, Mark Johnston wrote: On Wed, Oct 23, 2013 at 09:30:09PM +0100, symbol...@gmx.com wrote: Hi, http://dtrace.org/blogs/brendan/2011/02/11/dtrace-pid-provider-arguments/ I

Re: new issues w/ dtrace aborting...

On Thu, Oct 17, 2013 at 01:06:58PM -0700, John-Mark Gurney wrote: I'm see this failure which is reproducable: # dtrace -s ./disklatencycmd.d -x evaltime=postinit -c ./catall Tracing... Hit Ctrl-C to end. Now, I have spent some time trying to debug this error and have gotten a stack trace:

Re: dtrace -c doesn't work?

On Tue, Oct 15, 2013 at 04:32:19PM -0700, John-Mark Gurney wrote: Well, I've decided to try to learn dtrace to do some benchmarking, and so I tried to use -c to measure what the command does... except it seems to fail... even the simple: dtrace -n 'syscall:::entry { @num[execname] =

Re: [dtrace-discuss] Re: pr_psargs on FreeBSD

On Sun, Sep 15, 2013 at 3:16 PM, Mark Johnston ma...@freebsd.org wrote: Hi! One of the problems with FreeBSD's DTrace implementation is that it doesn't have a good way of getting the arguments of a given process. This is because of the way that they're stored, which is as a single

pr_psargs on FreeBSD

Hi! One of the problems with FreeBSD's DTrace implementation is that it doesn't have a good way of getting the arguments of a given process. This is because of the way that they're stored, which is as a single buffer with null-terminator between consecutive arguments. In particular, there is no