NULL pointer dereference after running dtrace script (linux 3.10) #61
Comments
|
Interesting .. it took an INT3 breakpoint trap and looked to see if this thanks On 22 July 2013 17:25, Azat Khuzhin notifications@github.com wrote:
|
|
can you show me your dtrace invocation? thanks On 22 July 2013 21:40, Paul Fox paul.d.fox@gmail.com wrote:
|
|
Sure, I will test this in non 3.10 in a day or so. And also I test simplest C/C++ program, and dtrace is fine with it. Here is dtrace invocation: I simplify it as I can, and the current version of script is hit the bug. On Tue, Jul 23, 2013 at 12:53 AM, dtrace4linux notifications@github.comwrote:
Respectfully |
|
I've tested 3.9 linux, and it had the same issue. uname -r3.9.0+ On Tue, Jul 23, 2013 at 12:57 AM, Azat Khuzhin a3at.mail@gmail.com wrote:
Respectfully |
|
Good .. that means its easier to find.
|
|
Any thoughts/news on this one? On Tue, Jul 23, 2013 at 2:21 PM, dtrace4linux notifications@github.comwrote:
Respectfully |
|
No - this obviously needs more debugging. The port from solaris to linux On 2 August 2013 23:11, Azat Khuzhin notifications@github.com wrote:
|
|
Thanks for reply. I've also tried to compile with CONFIG_DEBUG_NOTIFIERS, but this And it is really not looks like race condition, because it reproduced On Sat, Aug 3, 2013 at 2:48 AM, dtrace4linux notifications@github.com wrote:
Respectfully |
I see this is happens in gdb:
gdb bt:
#0 taskq_dispatch2 (tq=0xffff88003712e600, func=0x0 <irq_stack_union>,
arg=0x0 <irq_stack_union>, flags=0, delay=1)
at /usr/src/dtrace4linux/build-3.11.0-rc4+/driver/taskq.c:263
dtrace4linux#1 0xffffffffa0369433 in timeout (
func=func@entry=0xffffffffa035c9d5 <fasttrap_pid_cleanup_cb>,
arg=arg@entry=0x0 <irq_stack_union>, ticks=ticks@entry=1)
at /usr/src/dtrace4linux/build-3.11.0-rc4+/driver/taskq.c:306
dtrace4linux#2 0xffffffffa035c9c0 in fasttrap_pid_cleanup ()
at /usr/src/dtrace4linux/build-3.11.0-rc4+/driver/fasttrap.c:505
dtrace4linux#3 0xffffffffa035cdbf in fasttrap_provider_retire (pid=<optimized out>,
name=0xffffffffa037eb8f "pid", name@entry=0x140ef <Address 0x140ef out of bounds>,
mprov=mprov@entry=0) at /usr/src/dtrace4linux/build-3.11.0-rc4+/driver/fasttrap.c:1713
dtrace4linux#4 0xffffffffa035ce08 in fasttrap_exec_exit (p=0xffff8800371d3b18)
at /usr/src/dtrace4linux/build-3.11.0-rc4+/driver/fasttrap.c:596
dtrace4linux#5 0xffffffffa0358c09 in proc_exit_notifier (n=<optimized out>, code=<optimized out>,
ptr=<optimized out>)
at /usr/src/dtrace4linux/build-3.11.0-rc4+/driver/dtrace_linux.c:2020
dtrace4linux#6 0xffffffff8139b2d3 in notifier_call_chain (
nl=nl@entry=0xffffffff81634da0 <task_exit_notifier+32>, val=val@entry=0,
v=v@entry=0xffff88007b62b040, nr_to_call=nr_to_call@entry=-1,
nr_calls=nr_calls@entry=0x0 <irq_stack_union>) at kernel/notifier.c:93
dtrace4linux#7 0xffffffff8105824b in __blocking_notifier_call_chain (
nh=nh@entry=0xffffffff81634d80 <task_exit_notifier>, val=val@entry=0,
v=0xffff88007b62b040, nr_to_call=nr_to_call@entry=-1,
nr_calls=nr_calls@entry=0x0 <irq_stack_union>) at kernel/notifier.c:314
dtrace4linux#8 0xffffffff81058273 in blocking_notifier_call_chain (
nh=nh@entry=0xffffffff81634d80 <task_exit_notifier>, val=val@entry=0,
v=<optimized out>) at kernel/notifier.c:325
dtrace4linux#9 0xffffffff810750f5 in profile_task_exit (task=<optimized out>) at kernel/profile.c:143
dtrace4linux#10 0xffffffff8103a3cf in do_exit ()
dtrace4linux#11 0xffffffff8103b87c in do_group_exit ()
dtrace4linux#12 0xffffffff81047522 in get_signal_to_deliver ()
dtrace4linux#13 0xffffffff81002176 in do_signal ()
dtrace4linux#14 0xffffffff810025d3 in do_notify_resume ()
dtrace4linux#15 <signal handler called>
dtrace4linux#16 0x00007fed3818fff8 in ?? ()
Refs dtrace4linux#61
|
It is a race condition which will most often fail. There are two procs ..
|
|
Also I have next kernel bt, after Program received signal SIGSEGV, Segmentation fault. On Wed, Aug 7, 2013 at 3:12 PM, dtrace4linux notifications@github.comwrote:
Respectfully |
Trying to run dtrace on PID, using dtrace script, and when function that I've trace entered/leaved get next error in kern.log, and after this PID is killed by: "Trace/breakpoint trap"
Don't pay attention to 2-6-39 it is just host name.
And also this one is after applying #60
But I don't event try to read /proc/dtrace/*, so that patchset mustn't affect this bug.
And BTW I have the same issue as in #58 when compiling (maybe this can affect)
The text was updated successfully, but these errors were encountered: