From: Jeff D. <jd...@ka...> - 2002-04-17 03:17:24
|
bo...@cm... said: > 2) Each time the new process created by idle_task is run (when it's in > the cpu_idle function), it immediately seg faults So where is the segfault happening? Jeff |
From: Jeff D. <jd...@ka...> - 2002-04-17 10:57:37
|
bo...@cm... said: > So I guess the segv happens the first instruction when the new thread > is run. You guess? What's the matter with getting a backtrace? > If the mm_struct is NULL the thread would have to seg fault, right? No. Jeff |
From: Ryan B. <bo...@cm...> - 2002-04-17 18:46:32
|
> What's the matter with getting a backtrace? > > Jeff > I need to run a backtrace on the seg faulting thread right? But I can't figure out how to do that, here's why... I can run a backtrace on the signal handler thread and get this (gdb) bt #0 0xa00f9124 in segv (address=0, ip=0, is_write=0, is_user=0) at trap_kern.c:48 #1 0xa00f9dd1 in segv_handler (sig=11, regs=0xa089037c) at trap_user.c:403 #2 0xa00f9fbf in sig_handler (sig=11, sc= {gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh = 0, edi = 2693480448, esi = 0, ebp = 2693348556, esp = 2693348368, ebx = 0, edx = 2693348388, ecx = 2685357426, eax = 0, trapno = 14, err = 4, eip = 0, cs = 35, __csh = 0, eflags = 66198, esp_at_signal = 2693348368, ss = 43, __ssh = 0, fpstate = 0x0, oldmask = 134217728, cr2 = 0}) at trap_user.c:472 #3 <signal handler called> But, I can't figure out how to run a back trace on the seg faulting thread. I had segv() print out current->prev_task->thread.extern_pid, and it said 16907. [rtb@cog18 ~]$ kill -USR1 16907 sleeping process 15602 got unexpected signal : 10 So it never dettaches that thread and then when I try to attach it in gdb I get... (gdb) att 16907 Attaching to program: /home/rtb/src/linux/linux, process 16907 ptrace: Operation not permitted. So what do I have to do to run a back trace on the seg faulting thread? -- Ryan Boder GPG Public Key at http://www.ece.cmu.edu/~rtb/icanoop.gpg |
From: Matt Z. <md...@de...> - 2002-04-17 20:21:53
|
On Wed, Apr 17, 2002 at 02:41:13PM -0400, Ryan Boder wrote: > I need to run a backtrace on the seg faulting thread right? But I can't > figure out how to do that, here's why... Try the technique given in: http://user-mode-linux.sourceforge.net/trouble.html Case 3 : Tracing thread panics caused by other threads -- - mdz |
From: Jeff D. <jd...@ka...> - 2002-04-17 20:11:06
|
bo...@cm... said: > I can run a backtrace on the signal handler thread and get this What's the signal handler thread? > #2 0xa00f9fbf in sig_handler (sig=11, sc= > {gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = > 43, __dsh = 0, edi = 2693480448, esi = 0, ebp = 2693348556, esp = > 2693348368, ebx = 0, edx = 2693348388, ecx = 2685357426, eax = 0, trapno > = 14, err = 4, eip = 0, cs = 35, __csh = 0, eflags = 66198, > esp_at_signal = 2693348368, ss = 43, __ssh = 0, fpstate = 0x0, oldmask = > 134217728, cr2 = 0}) This thread tried branching to 0. That certainly seems worth looking into. > I had segv() print out current->prev_task->thread.extern_pid, and it > said 16907. Why? The current task is current, as the name might suggest. > So what do I have to do to run a back trace on the seg faulting > thread? Figuring out which thread that is would be a good start. I suspect the stack you want is the one above. Jeff |
From: Ryan B. <bo...@cm...> - 2002-04-18 03:01:44
|
On Wed, 2002-04-17 at 17:09, Jeff Dike wrote: > bo...@cm... said: > > I can run a backtrace on the signal handler thread and get this > > What's the signal handler thread? Probably a sign that I don't know much about how SMP works. > > #2 0xa00f9fbf in sig_handler (sig=11, sc= > > {gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = > > 43, __dsh = 0, edi = 2693480448, esi = 0, ebp = 2693348556, esp = > > 2693348368, ebx = 0, edx = 2693348388, ecx = 2685357426, eax = 0, trapno > > = 14, err = 4, eip = 0, cs = 35, __csh = 0, eflags = 66198, > > esp_at_signal = 2693348368, ss = 43, __ssh = 0, fpstate = 0x0, oldmask = > > 134217728, cr2 = 0}) > > This thread tried branching to 0. That certainly seems worth looking into. > > > I had segv() print out current->prev_task->thread.extern_pid, and it > > said 16907. > > Why? It seemed from reading your debugging howtos that the signal handler was a new thread, and the thread that caused the seg fault would be current->prev_task. Plus the fact that the back trace in gdb starts with #3 <signal handler called> made it seem like that was the first function of the thread, implying that the thread that seg faulted would have just been scheduled out. I was hoping that current->prev_task would have the stack that ends with the function which caused the seg fault. So I guess from your answer I was wrong about that. Something tells me my project is doomed, since I need a working SMP kernel before I can even start the project. -- Ryan Boder GPG Public Key at http://www.ece.cmu.edu/~rtb/icanoop.gpg |
From: Jeff D. <jd...@ka...> - 2002-04-18 03:22:06
|
bo...@cm... said: > It seemed from reading your debugging howtos that the signal handler > was a new thread, and the thread that caused the seg fault would be > current->prev_task. You were following the recipe for debugging a hung process, which clearly isn't applicable here because you don't even have processes yet, let alone hung ones. > Something tells me my project is doomed, since I need a working SMP > kernel before I can even start the project. The preliminary project, getting UML SMP working certainly isn't doomed. It's not that hard, but it does require some understanding of how UML works. Jeff |
From: Ryan B. <bo...@cm...> - 2002-04-17 04:20:47
|
On Wed, 2002-04-17 at 00:19, Jeff Dike wrote: > bo...@cm... said: > > 2) Each time the new process created by idle_task is run (when it's in > > the cpu_idle function), it immediately seg faults > > So where is the segfault happening? > > Well, I put a printk right after the call to do_fork, and it only printed for the calling thread, never for the new thread. So I guess the segv happens the first instruction when the new thread is run. Which would make sense because the segv function said that current->mm == NULL. If the mm_struct is NULL the thread would have to seg fault, right? -- Ryan Boder GPG Public Key at http://www.ece.cmu.edu/~rtb/icanoop.gpg |