Re: DTrace broken on 9.0-Release?
On Wed, Jun 13, 2012 at 9:33 PM, Ryan Goodfellow rgood...@eecs.wsu.edu wrote:
Hi FreeBSD community,
Today I downloaded and installed FreeBSD 9.0-RELEASE and followed the
directions from http://wiki.freebsd.org/DTrace to get DTrace up and
running. The output of DTrace instrumenting a simple program, however, is
not correct. The program is as follows:
// test.cc
#includecstdlib
int main(void) {
for(int i = 0; i 5; i++) {
malloc(47);
}
}
then compiling and running DTrace as follows:
g++ test.cc -o test
dtrace -n 'pid$target::malloc:entry{ }' -c ./test
The correct output for this example is something to the tune of:
dtrace: description 'pid$target::malloc:entry' matched 2 probes
dtrace: pid 95236 has exited
CPU ID FUNCTION:NAME
0 188748 malloc:entry
0 188748 malloc:entry
0 188748 malloc:entry
0 188748 malloc:entry
0 188748 malloc:entry
(this from a machine with the same code running DTrace)
The DTrace session should also make an immediate exit on completion. On
FreeBSD I have the following
CPU ID FUNCTION:NAME
2 42213 malloc:entry
and the execution does either not exit on it's own or hangs, it requires a
ctrl-c.
I followed the instructions from the FreeBSD site exactly, compiling and
installing the custom kernel. I used both clang++ and g++ for compilation
with the same result. The system has even completely hung on other attempts.
Is DTrace not something that should be relied upon in FreeBSD? I have also
tried this on the latest 10-CURRENT build with the same result.
Did you compile world with -fno-omit-frame-pointer ? I didn't
doing that (at least) and I'm seeing the same things that you are
seeing.
Thanks,
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: DTrace broken on 9.0-Release?
Ryan Goodfellow rgood...@eecs.wsu.edu wrote:
Today I downloaded and installed FreeBSD 9.0-RELEASE and followed the
directions from http://wiki.freebsd.org/DTrace to get DTrace up and
running. The output of DTrace instrumenting a simple program, however,
is not correct. The program is as follows:
// test.cc
#includecstdlib
int main(void) {
for(int i = 0; i 5; i++) {
malloc(47);
}
}
then compiling and running DTrace as follows:
g++ test.cc -o test
dtrace -n 'pid$target::malloc:entry{ }' -c ./test
The correct output for this example is something to the tune of:
dtrace: description 'pid$target::malloc:entry' matched 2 probes
dtrace: pid 95236 has exited
CPU IDFUNCTION:NAME
0 188748 malloc:entry
0 188748 malloc:entry
0 188748 malloc:entry
0 188748 malloc:entry
0 188748 malloc:entry
(this from a machine with the same code running DTrace)
The DTrace session should also make an immediate exit on completion. On
FreeBSD I have the following CPU IDFUNCTION:NAME
2 42213 malloc:entry
and the execution does either not exit on it's own or hangs, it requires
a ctrl-c.
Doesn't work for me either on 10-CURRENT amd64.
Converting it to C doesn't make a difference, it works if
one changes the loop to for (;;), though.
I followed the instructions from the FreeBSD site exactly, compiling and
installing the custom kernel. I used both clang++ and g++ for
compilation with the same result. The system has even completely hung
on other attempts.
Is DTrace not something that should be relied upon in FreeBSD? I have
also tried this on the latest 10-CURRENT build with the same result.
In my opinion the problem with DTrace on FreeBSD is that while it's
known to be incomplete, there doesn't seem to be documentation
available about which parts are supposed to work already and which
aren't.
For example the trivial example program at:
http://wiki.freebsd.org/DTrace/userland (which works for me) doesn't
actually use a counting loop, so maybe dtracing your example program
isn't supposed to work yet and never did on FreeBSD.
Without documentation it's hard to tell.
Fabian
signature.asc
Description: PGP signature
Re: DTrace broken on 9.0-Release?
Top post.
File a PR and assign it to me (gnn) please.
I'm on vacation until Sunday but I am actively working on DTrace when I'm not
on vacation.
Best,
Geo
On Jun 14, 2012, at 02:53 , Fabian Keil wrote:
Ryan Goodfellow rgood...@eecs.wsu.edu wrote:
Today I downloaded and installed FreeBSD 9.0-RELEASE and followed the
directions from http://wiki.freebsd.org/DTrace to get DTrace up and
running. The output of DTrace instrumenting a simple program, however,
is not correct. The program is as follows:
// test.cc
#includecstdlib
int main(void) {
for(int i = 0; i 5; i++) {
malloc(47);
}
}
then compiling and running DTrace as follows:
g++ test.cc -o test
dtrace -n 'pid$target::malloc:entry{ }' -c ./test
The correct output for this example is something to the tune of:
dtrace: description 'pid$target::malloc:entry' matched 2 probes
dtrace: pid 95236 has exited
CPU IDFUNCTION:NAME
0 188748 malloc:entry
0 188748 malloc:entry
0 188748 malloc:entry
0 188748 malloc:entry
0 188748 malloc:entry
(this from a machine with the same code running DTrace)
The DTrace session should also make an immediate exit on completion. On
FreeBSD I have the following CPU IDFUNCTION:NAME
2 42213 malloc:entry
and the execution does either not exit on it's own or hangs, it requires
a ctrl-c.
Doesn't work for me either on 10-CURRENT amd64.
Converting it to C doesn't make a difference, it works if
one changes the loop to for (;;), though.
I followed the instructions from the FreeBSD site exactly, compiling and
installing the custom kernel. I used both clang++ and g++ for
compilation with the same result. The system has even completely hung
on other attempts.
Is DTrace not something that should be relied upon in FreeBSD? I have
also tried this on the latest 10-CURRENT build with the same result.
In my opinion the problem with DTrace on FreeBSD is that while it's
known to be incomplete, there doesn't seem to be documentation
available about which parts are supposed to work already and which
aren't.
For example the trivial example program at:
http://wiki.freebsd.org/DTrace/userland (which works for me) doesn't
actually use a counting loop, so maybe dtracing your example program
isn't supposed to work yet and never did on FreeBSD.
Without documentation it's hard to tell.
Fabian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: DTrace broken on 9.0-Release?
Hi everyone, and thank you for the very prompt responses.
I did indeed compile world with CFLAGS+=-fno-omit-frame-poiner in my make.conf.
I will file the PR shortly.
Thank You
Ryan G
On Jun 14, 2012, at 9:00 AM, George Neville-Neil g...@neville-neil.com wrote:
Top post.
File a PR and assign it to me (gnn) please.
I'm on vacation until Sunday but I am actively working on DTrace when I'm not
on vacation.
Best,
Geo
On Jun 14, 2012, at 02:53 , Fabian Keil wrote:
Ryan Goodfellow rgood...@eecs.wsu.edu wrote:
Today I downloaded and installed FreeBSD 9.0-RELEASE and followed the
directions from http://wiki.freebsd.org/DTrace to get DTrace up and
running. The output of DTrace instrumenting a simple program, however,
is not correct. The program is as follows:
// test.cc
#includecstdlib
int main(void) {
for(int i = 0; i 5; i++) {
malloc(47);
}
}
then compiling and running DTrace as follows:
g++ test.cc -o test
dtrace -n 'pid$target::malloc:entry{ }' -c ./test
The correct output for this example is something to the tune of:
dtrace: description 'pid$target::malloc:entry' matched 2 probes
dtrace: pid 95236 has exited
CPU IDFUNCTION:NAME
0 188748 malloc:entry
0 188748 malloc:entry
0 188748 malloc:entry
0 188748 malloc:entry
0 188748 malloc:entry
(this from a machine with the same code running DTrace)
The DTrace session should also make an immediate exit on completion. On
FreeBSD I have the following CPU IDFUNCTION:NAME
2 42213 malloc:entry
and the execution does either not exit on it's own or hangs, it requires
a ctrl-c.
Doesn't work for me either on 10-CURRENT amd64.
Converting it to C doesn't make a difference, it works if
one changes the loop to for (;;), though.
I followed the instructions from the FreeBSD site exactly, compiling and
installing the custom kernel. I used both clang++ and g++ for
compilation with the same result. The system has even completely hung
on other attempts.
Is DTrace not something that should be relied upon in FreeBSD? I have
also tried this on the latest 10-CURRENT build with the same result.
In my opinion the problem with DTrace on FreeBSD is that while it's
known to be incomplete, there doesn't seem to be documentation
available about which parts are supposed to work already and which
aren't.
For example the trivial example program at:
http://wiki.freebsd.org/DTrace/userland (which works for me) doesn't
actually use a counting loop, so maybe dtracing your example program
isn't supposed to work yet and never did on FreeBSD.
Without documentation it's hard to tell.
Fabian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
DTrace broken on 9.0-Release?
Hi FreeBSD community,
Today I downloaded and installed FreeBSD 9.0-RELEASE and followed the
directions from http://wiki.freebsd.org/DTrace to get DTrace up and running.
The output of DTrace instrumenting a simple program, however, is not correct.
The program is as follows:
// test.cc
#includecstdlib
int main(void) {
for(int i = 0; i 5; i++) {
malloc(47);
}
}
then compiling and running DTrace as follows:
g++ test.cc -o test
dtrace -n 'pid$target::malloc:entry{ }' -c ./test
The correct output for this example is something to the tune of:
dtrace: description 'pid$target::malloc:entry' matched 2 probes
dtrace: pid 95236 has exited
CPU IDFUNCTION:NAME
0 188748 malloc:entry
0 188748 malloc:entry
0 188748 malloc:entry
0 188748 malloc:entry
0 188748 malloc:entry
(this from a machine with the same code running DTrace)
The DTrace session should also make an immediate exit on completion. On FreeBSD
I have the following
CPU IDFUNCTION:NAME
2 42213 malloc:entry
and the execution does either not exit on it's own or hangs, it requires a
ctrl-c.
I followed the instructions from the FreeBSD site exactly, compiling and
installing the custom kernel. I used both clang++ and g++ for compilation with
the same result. The system has even completely hung on other attempts.
Is DTrace not something that should be relied upon in FreeBSD? I have also
tried this on the latest 10-CURRENT build with the same result.
Thanks
Ryan G___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: DTrace broken on 9.0-Release?
Hi, Would you please make sure you file a PR with exactly what you've just listed above? You've gone into great detail here, so it should be easy to reproduce. What happens if you name it 'test.c' and compile it with cc (as a C source) rather than C++? Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Is it Dtrace broken on HEAD?
Hello fellows,
Is it Dtrace broken on HEAD?
root@controllerB:/sys/amd64/conf # dtrace -n 'syscall::open*:entry {
printf(%s %s,execname,copyinstr(arg0)); }'
*dtrace: invalid probe specifier syscall::open*:entry { printf(%s
%s,execname,copyinstr(arg0)); }: /usr/lib/dtrace/psinfo.d, line 37:
syntax error near uid_t*
root@controllerB:/sys/amd64/conf # uname -a
FreeBSD controllerB.la.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Tue May 29
13:54:25 CST 2012 r...@controllerb.la.com:/usr/obj/usr/src/sys/LA amd64
Best Regards,
--
Marcelo Araujo
ara...@freebsd.org
--
Marcelo Araujo
ara...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Is it Dtrace broken on HEAD?
On Wed, May 30, 2012 at 6:37 AM, Marcelo Araujo araujobsdp...@gmail.com wrote:
Hello fellows,
Is it Dtrace broken on HEAD?
root@controllerB:/sys/amd64/conf # dtrace -n 'syscall::open*:entry {
printf(%s %s,execname,copyinstr(arg0)); }'
*dtrace: invalid probe specifier syscall::open*:entry { printf(%s
%s,execname,copyinstr(arg0)); }: /usr/lib/dtrace/psinfo.d, line 37:
syntax error near uid_t*
root@controllerB:/sys/amd64/conf # uname -a
FreeBSD controllerB.la.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Tue May 29
13:54:25 CST 2012 r...@controllerb.la.com:/usr/obj/usr/src/sys/LA amd64
Best Regards,
--
Marcelo Araujo
ara...@freebsd.org
I know that I've seen this before when I've built improperly, but I
can't exactly remember what the root cause was. Do you have CTF data
in your kernel(i.e. does ctfdump /boot/kernel/kernel give output?).
If not then you forgot to build with WITH_CTF=1
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: DTrace Broken?
On Fri, 18 Feb 2011, Shawn Webb wrote: Hey fellow current users, Looks like dtrace is broken in current: # dtrace -l -f acl dtrace: invalid probe specifier acl: /usr/lib/dtrace/psinfo.d, line 37: syntax error near uid_t Error messages along these lines almost always mean that the kernel was built without WITH_CTF (causing dtrace to be unable to find the type information it requires). Robert Line 37 shows: uid_t pr_uid; /* real user id */ Looks good to me, but why is dtrace complaining? Thanks, Shawn Webb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
DTrace Broken?
Hey fellow current users, Looks like dtrace is broken in current: # dtrace -l -f acl dtrace: invalid probe specifier acl: /usr/lib/dtrace/psinfo.d, line 37: syntax error near uid_t Line 37 shows: uid_t pr_uid; /* real user id */ Looks good to me, but why is dtrace complaining? Thanks, Shawn Webb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: DTrace Broken?
Disregard. I didn't have ksh93 installed. The handbook implies that it's needed only for DTrace Toolkit, not DTrace itself. Installing ksh93 is required for DTrace proper to work. On Fri, Feb 18, 2011 at 9:36 PM, Shawn Webb latt...@gmail.com wrote: Hey fellow current users, Looks like dtrace is broken in current: # dtrace -l -f acl dtrace: invalid probe specifier acl: /usr/lib/dtrace/psinfo.d, line 37: syntax error near uid_t Line 37 shows: uid_t pr_uid; /* real user id */ Looks good to me, but why is dtrace complaining? Thanks, Shawn Webb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: DTrace Broken?
On Fri, 18 Feb 2011 21:50:59 -0700 Shawn Webb latt...@gmail.com wrote: Disregard. I didn't have ksh93 installed. The handbook implies that it's needed only for DTrace Toolkit, not DTrace itself. Installing ksh93 is required for DTrace proper to work. This cannot possibly be true. % sudo dtrace -l -f acl ID PROVIDERMODULE FUNCTION NAME 1840 dtmalloc acl malloc 1841 dtmalloc act free -- Alexander Kabaev signature.asc Description: PGP signature
