DTrace userland
I'm using FreeBSD 9.0 on amd64 in VMware Fusion and trying to DTrace userland programs. I think I must be doing something wrong. I recompiled my kernel and world, following the instructions at http://wiki.freebsd.org/DTrace and I've read http://wiki.freebsd.org/DTrace/userland: The test.c pid provider example worked fine for me: $ sudo dtrace -s pid.d -c ./test dtrace: script 'pid.d' matched 2 probes dtrace: buffer size lowered to 1m CPU IDFUNCTION:NAME 0 43030 main:entry 0 43031 sleep:entry 0 43031 sleep:entry 0 43031 sleep:entry As does a simple probe of test.c specified with the -n option: [marca@freebsd9-0 ~]$ sudo dtrace -n 'pid$target:test:main:entry' -c ./test dtrace: description 'pid$target:test:main:entry' matched 1 probe dtrace: buffer size lowered to 1m CPU IDFUNCTION:NAME 0 43030 main:entry When I start trying to dtrace other programs, things don't go so well... $ sudo dtrace -n ":::entry" -c /usr/local/bin/python Python 2.4.5 (#2, Dec 5 2011, 15:19:09) [GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd9 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.getpid() 1603 >>> dtrace: failed to control pid 1603: process exited with status 0 $ sudo dtrace -n 'pid$target:::entry' -c '/bin/cat hello_world.txt' dtrace: description 'pid$target:::entry' matched 3315 probes dtrace: buffer size lowered to 1m CPU IDFUNCTION:NAME 0 43448 _rtld_bind:entry 0 43903 rlock_acquire:entry 0 43125def_thread_set_flag:entry (Had to hit Ctrl-C to exit; it never displayed hello_world.txt to stdout) [marca@freebsd9-0 /usr/ports/sysutils/coreutils]$ sudo make install ... [marca@freebsd9-0 /usr/ports/sysutils/coreutils]$ sudo dtrace -n 'pid$target:::entry' -c '/usr/local/bin/gcat config.log' dtrace: description 'pid$target:::entry' matched 3823 probes dtrace: buffer size lowered to 1m CPU IDFUNCTION:NAME 0 43524 _rtld_bind:entry 0 43979 rlock_acquire:entry 0 43201def_thread_set_flag:entry ^C $ sudo dtrace -n 'pid$target:cat:main:entry' -c '/bin/cat hello_world.txt' causes a kernel panic. According to the core.txt file, it was a "Fatal trap 10: trace trap while in kernel mode" and here's the KDB backtrace: KDB: stack backtrace: #0 0x8089025e at kdb_backtrace+0x5e #1 0x80858ce7 at panic+0x187 #2 0x80b4bf20 at trap_fatal+0x290 #3 0x80b4c540 at trap+0x180 #4 0x80b36963 at calltrap+0x8 #5 0x8162583d at dtrace_assfail+0x2d #6 0x8188aa2e at fasttrap_provider_free+0x1de #7 0x8188ad13 at fasttrap_pid_cleanup_cb+0x1c3 #8 0x8086dfa1 at softclock+0x3a1 #9 0x8082d724 at intr_event_execute_handlers+0x104 #10 0x8082eee4 at ithread_loop+0xa4 #11 0x8082a34f at fork_exit+0x11f #12 0x80b36e8e at fork_trampoline+0xe [marca@freebsd9-0 /usr/ports/sysutils/coreutils]$ sudo dtrace -n 'pid$target:gcat::entry' -c '/usr/local/bin/gcat config.log' (Another kernel panic) I can provide full crash dumps if necessary. Any idea what's going on here? Cheers, Marc ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: DTrace userland
Another strange behavior: [Tab 1] $ /bin/sleep 300 & [1] 1806 [Tab 2] $ sudo dtrace -n 'pid1806:sleep::entry' $ echo $? 158 [Tab 1] [1]+ Killed: 9 /bin/sleep 300 Something seems very wrong that DTrace is killing processes and causing kernel panics. Marc On Mon, Feb 27, 2012 at 10:22 PM, Marc Abramowitz wrote: > I'm using FreeBSD 9.0 on amd64 in VMware Fusion and trying to DTrace > userland programs. I think I must be doing something wrong. > > I recompiled my kernel and world, following the instructions at > http://wiki.freebsd.org/DTrace and I've read > http://wiki.freebsd.org/DTrace/userland: > > The test.c pid provider example worked fine for me: > > $ sudo dtrace -s pid.d -c ./test > dtrace: script 'pid.d' matched 2 probes > dtrace: buffer size lowered to 1m > CPU IDFUNCTION:NAME > 0 43030 main:entry > 0 43031 sleep:entry > 0 43031 sleep:entry > 0 43031 sleep:entry > > As does a simple probe of test.c specified with the -n option: > > [marca@freebsd9-0 ~]$ sudo dtrace -n 'pid$target:test:main:entry' -c > ./test > dtrace: description 'pid$target:test:main:entry' matched 1 probe > dtrace: buffer size lowered to 1m > CPU IDFUNCTION:NAME > 0 43030 main:entry > > When I start trying to dtrace other programs, things don't go so well... > > $ sudo dtrace -n ":::entry" -c /usr/local/bin/python > Python 2.4.5 (#2, Dec 5 2011, 15:19:09) > [GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd9 > Type "help", "copyright", "credits" or "license" for more information. > >>> import os > >>> os.getpid() > 1603 > >>> > dtrace: failed to control pid 1603: process exited with status 0 > > $ sudo dtrace -n 'pid$target:::entry' -c '/bin/cat hello_world.txt' > dtrace: description 'pid$target:::entry' matched 3315 probes > dtrace: buffer size lowered to 1m > CPU IDFUNCTION:NAME > 0 43448 _rtld_bind:entry > 0 43903 rlock_acquire:entry > 0 43125def_thread_set_flag:entry > (Had to hit Ctrl-C to exit; it never displayed hello_world.txt to stdout) > > [marca@freebsd9-0 /usr/ports/sysutils/coreutils]$ sudo make install > ... > [marca@freebsd9-0 /usr/ports/sysutils/coreutils]$ sudo dtrace -n > 'pid$target:::entry' -c '/usr/local/bin/gcat config.log' > dtrace: description 'pid$target:::entry' matched 3823 probes > dtrace: buffer size lowered to 1m > CPU IDFUNCTION:NAME > 0 43524 _rtld_bind:entry > 0 43979 rlock_acquire:entry > 0 43201def_thread_set_flag:entry > ^C > > $ sudo dtrace -n 'pid$target:cat:main:entry' -c '/bin/cat hello_world.txt' > causes a kernel panic. > According to the core.txt file, it was a "Fatal trap 10: trace trap while > in kernel mode" and here's the KDB backtrace: > > KDB: stack backtrace: > #0 0x8089025e at kdb_backtrace+0x5e > #1 0x80858ce7 at panic+0x187 > #2 0x80b4bf20 at trap_fatal+0x290 > #3 0x80b4c540 at trap+0x180 > #4 0x80b36963 at calltrap+0x8 > #5 0x8162583d at dtrace_assfail+0x2d > #6 0x8188aa2e at fasttrap_provider_free+0x1de > #7 0x8188ad13 at fasttrap_pid_cleanup_cb+0x1c3 > #8 0x8086dfa1 at softclock+0x3a1 > #9 0x8082d724 at intr_event_execute_handlers+0x104 > #10 0x8082eee4 at ithread_loop+0xa4 > #11 0x8082a34f at fork_exit+0x11f > #12 0x80b36e8e at fork_trampoline+0xe > > [marca@freebsd9-0 /usr/ports/sysutils/coreutils]$ sudo dtrace -n > 'pid$target:gcat::entry' -c '/usr/local/bin/gcat config.log' > (Another kernel panic) > > I can provide full crash dumps if necessary. > > Any idea what's going on here? > > Cheers, > Marc > > > > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: DTrace userland
Here's another way to cause a kernel panic:
[marca@freebsd9-0 ~]$ sudo kldload dtraceall
[marca@freebsd9-0 ~]$ cat -n test.c
1 #include
2
3 int main()
4 {
5sleep(15);
6
7FILE *fp = fopen("hello.txt", "w");
8fprintf(fp, "Here I am at %s:%d.\n", __FILE__, __LINE__);
9fclose(fp);
10 }
[marca@freebsd9-0 ~]$ gcc test.c -o test
[marca@freebsd9-0 ~]$ sudo dtrace -n 'pid$target:test:main:entry' -c ./test
dtrace: description 'pid$target:test:main:entry' matched 1 probe
dtrace: buffer size lowered to 1m
CPU IDFUNCTION:NAME
0 43030 main:entry
(Kernel panic! After reboot)
[marca@freebsd9-0 ~]$ cat hello.txt
Here I am at test.c:8.
Interestingly, the crash doesn't occur until after the sleep and the
fprintf call, so it looks the kernel panic happens as a result of the
traced process _exiting_...
Marc
On Mon, Feb 27, 2012 at 11:10 PM, Marc Abramowitz wrote:
> Another strange behavior:
>
> [Tab 1]
> $ /bin/sleep 300 &
> [1] 1806
>
> [Tab 2]
> $ sudo dtrace -n 'pid1806:sleep::entry'
> $ echo $?
> 158
>
> [Tab 1]
> [1]+ Killed: 9 /bin/sleep 300
>
> Something seems very wrong that DTrace is killing processes and causing
> kernel panics.
>
> Marc
>
> On Mon, Feb 27, 2012 at 10:22 PM, Marc Abramowitz wrote:
>
>> I'm using FreeBSD 9.0 on amd64 in VMware Fusion and trying to DTrace
>> userland programs. I think I must be doing something wrong.
>>
>> I recompiled my kernel and world, following the instructions at
>> http://wiki.freebsd.org/DTrace and I've read
>> http://wiki.freebsd.org/DTrace/userland:
>>
>> The test.c pid provider example worked fine for me:
>>
>> $ sudo dtrace -s pid.d -c ./test
>> dtrace: script 'pid.d' matched 2 probes
>> dtrace: buffer size lowered to 1m
>> CPU IDFUNCTION:NAME
>> 0 43030 main:entry
>> 0 43031 sleep:entry
>> 0 43031 sleep:entry
>> 0 43031 sleep:entry
>>
>> As does a simple probe of test.c specified with the -n option:
>>
>> [marca@freebsd9-0 ~]$ sudo dtrace -n 'pid$target:test:main:entry' -c
>> ./test
>> dtrace: description 'pid$target:test:main:entry' matched 1 probe
>> dtrace: buffer size lowered to 1m
>> CPU IDFUNCTION:NAME
>> 0 43030 main:entry
>>
>> When I start trying to dtrace other programs, things don't go so well...
>>
>> $ sudo dtrace -n ":::entry" -c /usr/local/bin/python
>> Python 2.4.5 (#2, Dec 5 2011, 15:19:09)
>> [GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd9
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import os
>> >>> os.getpid()
>> 1603
>> >>>
>> dtrace: failed to control pid 1603: process exited with status 0
>>
>> $ sudo dtrace -n 'pid$target:::entry' -c '/bin/cat hello_world.txt'
>> dtrace: description 'pid$target:::entry' matched 3315 probes
>> dtrace: buffer size lowered to 1m
>> CPU IDFUNCTION:NAME
>> 0 43448 _rtld_bind:entry
>> 0 43903 rlock_acquire:entry
>> 0 43125def_thread_set_flag:entry
>> (Had to hit Ctrl-C to exit; it never displayed hello_world.txt to stdout)
>>
>> [marca@freebsd9-0 /usr/ports/sysutils/coreutils]$ sudo make install
>> ...
>> [marca@freebsd9-0 /usr/ports/sysutils/coreutils]$ sudo dtrace -n
>> 'pid$target:::entry' -c '/usr/local/bin/gcat config.log'
>> dtrace: description 'pid$target:::entry' matched 3823 probes
>> dtrace: buffer size lowered to 1m
>> CPU IDFUNCTION:NAME
>> 0 43524 _rtld_bind:entry
>> 0 43979 rlock_acquire:entry
>> 0 43201def_thread_set_flag:entry
>> ^C
>>
>> $ sudo dtrace -n 'pid$target:cat:main:entry' -c '/bin/cat hello_world.txt'
>> causes a kernel panic.
>> According to the core.txt file, it was a "Fatal trap 10: trace trap while
>> in kernel mode" and here's the KDB backtrace:
>>
>> KDB: stack backtrace:
>> #0 0x8089025e at kdb_backtrace+0x5e
>> #1 0x80858ce7 at panic+0x187
>> #2 0x80b4bf20 at trap_fata
Re: DTrace userland
On Tue, Feb 28, 2012 at 12:58 PM, Rui Paulo wrote: > Please file a PR. These are problems that we have to fix. I submitted a PR for the kernel panic at http://www.freebsd.org/cgi/query-pr.cgi?pr=165541 Marc ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: DTrace userland
On Tue, Feb 28, 2012 at 12:24 PM, Marc Abramowitz wrote: > Here's another way to cause a kernel panic: > > [marca@freebsd9-0 ~]$ sudo kldload dtraceall > ... > [marca@freebsd9-0 ~]$ sudo dtrace -n 'pid$target:test:main:entry' -c > ./test > dtrace: description 'pid$target:test:main:entry' matched 1 probe > dtrace: buffer size lowered to 1m > CPU IDFUNCTION:NAME > 0 43030 main:entry > (Kernel panic! After reboot) > > I submitted a PR for this kernel panic at http://www.freebsd.org/cgi/query-pr.cgi?pr=165541 Marc ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
dtrace/userland causing segmentation fault
hello freebsd gurus...
i'm currently using FreeBSD 9.0-CURRENT-201101...
dtrace is enable and working
[root@ ~]# dtrace -l | tail -5
41473profile tick-1000
41474profile tick-5000
41475profile tick-1sec
41476 database5533db main
query-done
41477 database5533db main
query-start
i´m trying to use dtrace with a very basic userland program and i´m
100% of the time getting segmentation faults...
-- probes definition file --
[root@ ~]# cat simple_probes.d
provider simple {
probe loop(int);
};
-- simple program --
[root@ ~]# cat simple.c
#include
#include "simple_probes.h"
int main() {
int i;
i=0;
while(1) {
printf("%d\n",i);
i++;
SIMPLE_LOOP(i);
}
return(0);
}
-- the steps i use to get the program compiled are --
[root@ ~]# dtrace -C -h -s simple_probes.d
[root@ ~]# gcc -c simple.c
[root@ ~]# dtrace -G -s simple_probes.d simple.o
[root@ ~]# gcc -lelf -o simple simple_probes.o simple.o
-- but when i run the program i always get segmentation fault >:( --
[root@ ~]# ./simple
0
Segmentation fault: 11 (core dumped)
i´ve been banging my head against a wall trying to troubleshoot this
issue with obviously no success...
have any of the freebsd gurus found a similar behavior in the past
regarding userland dtrace?
any pointers/links/words of encouragement will be greatly appreciated...
regards,
javier
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
FreeBSD 9.0-RC1 and DTrace Userland Probes
I upgraded my box so that I can rock the userland DTrace probes. I have been
following the example at: http://wiki.freebsd.org/DTrace/userland
When I am ready to build my test probe, I run 'make' as the example shows. The
result of that is the following:
cc -O2 -pipe -fno-omit-frame-pointer -std=gnu99 -fstack-protector -c test.c
cc -O2 -pipe -fno-omit-frame-pointer -std=gnu99 -fstack-protector -o test
test.o
test.o: In function `main':
test.c:(.text+0x29): undefined reference to `__dtrace_prober___probe__before'
test.c:(.text+0x45): undefined reference to `__dtrace_prober___probe__after'
*** Error code 1
Same idea as the example, but I just changed the names around. Well, so I
thought I would be smart and compile just the object file with:
dtrace -G -s prober.d
And that stalls. `truss` is showing that dtrace is stalling after a mmap, with
what looks to be a valid returned address.
/* provider.d */
provider prober {
probe probe__before(char *);
probe probe__after(char *);
};
/* test.c */
#include
#include
#include "provider.h"
int main(void)
{
struct timeval tv;
for ( ;; )
{
sleep(1);
PROBER_PROBE_BEFORE("foo");
gettimeofday(&tv, NULL);
PROBER_PROBE_AFTER("bar");
}
return 0;
}
Any insight would be wonderful.
Thanks!
-Matt
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
