Random Segfault when tracing commands.

[sdimitro]

Tried tracing the ls command with the following one-liner:

dtrace -c 'ls' -n 'syscall:::entry /pid == $target/ {@[probefunc] = count();}'

the output was the following:

$ dtrace -c 'ls' -n 'syscall:::entry /pid == $target/ {@[probefunc] = count();}' parent: waiting for child parent: after waitpid pid=3719 status=137f Segmentation fault

I run Ubuntu 12.04 LTS and I wanted to try a couple of examples from the dtrace book. I don't know if that helps at all but I used gdb to see where the segfault came from and got this:

Starting program: /usr/sbin/dtrace -c 'ls' -n 'syscall:::entry /pid == $target/ {@[probefunc] = count();}' [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". parent: waiting for child child 3420 about to exec ls parent: after waitpid pid=3420 status=57f [New Thread 0x7f73a7b75700 (LWP 3421)]

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f73a7b75700 (LWP 3421)] 0x0000000000462ce2 in rd_loadobj_iter (rap=0xffffffffa0001da0, cb=0x47dc2f >, client_data=0x1719820) at rtld_db.c:196 196 snprintf(buf, sizeof buf, "/proc/%d/maps", rap->rd_pid);

It seems like the address of the 'rap' argument passed to the function is invalid. Hope I am not duplicating an issue here.

[dtrace4linux]

Fix available. Missing prototype caused ptr vs int extension issues. If you run 'dtrace -c ls' or a variant of that - it appears to work, but you will see some extra debug on output and I got some issue with systemic response issue (not sure it properly detects the proc exit).

On 23 June 2013 04:27, sdimitro notifications@github.com wrote:

Tried tracing the ls command with the following one-liner:

dtrace -c 'ls' -n 'syscall:::entry /pid == $target/ {@[probefunc] = count();}'

the output was the following:

$ dtrace -c 'ls' -n 'syscall:::entry /pid == $target/ {@[probefunc] = count();}' parent: waiting for child parent: after waitpid pid=3719 status=137f Segmentation fault

I run Ubuntu 12.04 LTS and I wanted to try a couple of examples from the dtrace book. I don't know if that helps at all but I used gdb to see where the segfault came from and got this:

Starting program: /usr/sbin/dtrace -c 'ls' -n 'syscall:::entry /pid == $target/ {@[probefunc] = count();}' [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". parent: waiting for child child 3420 about to exec ls parent: after waitpid pid=3420 status=57f [New Thread 0x7f73a7b75700 (LWP 3421)]

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f73a7b75700 (LWP 3421)] 0x0000000000462ce2 in rd_loadobj_iter (rap=0xffffffffa0001da0, cb=0x47dc2f

, client_data=0x1719820) at rtld_db.c:196 196 snprintf(buf, sizeof buf, "/proc/%d/maps", rap->rd_pid);

It seems like the address of the 'rap' argument passed to the function is invalid. Hope I am not duplicating an issue here.

— Reply to this email directly or view it on GitHubhttps://github.com/dtrace4linux/linux/issues/57 .

[sdimitro]

Thanks for the quick reply! Yes it seems that it doesn't segfault any more. On the other hand when I ran the same command now, I get something like this:

...... proc-stub:rd_event_enable proc-stub:rd_errstr err=26 ..... dtrace: processing aborted: No such device ....(output of ls after that)

So still there seems to be a problem here as it doesn't seem to trace the command. But I assume that is not the issue that you are talking about, you said it worked for you right?