user-mode-linux-devel

Re: [User-mode-linux-devel] Re: [User-mode-linux-user] Re: User-mode linux stack overflow: could

[Jeff D. <jd...@ka...>]

> You had discussed enlarging the stack.  Is that considered a temporary
> workaround, technically prohibitive, or already in CVS? ;-)

None of the above.

What I'm going to do is allocate 4 pages for the stack and task_struct, and 
unmap the third, giving two pages for the stack and a guard page for the 
task_struct.

I'll put it in when I get back.

				Jeff

[User-mode-linux-devel] Re: User-mode linux stack overflow: could be generic problem

[Robert R. <ip...@di...>]

Re: [User-mode-linux-devel] Re: [User-mode-linux-user] Re: User-mode linux stack overflow: could

[William S. <wst...@po...>]

On Tue, 10 Oct 2000, Jeff Dike wrote:

> Anyway, that particular patch is no great prize.  Is there some reason
> you particularly want it?
> 
> I'm going to release that change in test10, but just as cleanup.  I've
> banged on it and it seems fine, and it reduces stack usage a little,
> but it doesn't really fix anyone's problems.

	You had discussed enlarging the stack.  Is that considered a
temporary workaround, technically prohibitive, or already in CVS? ;-)
	Cheers,
	- Bill

---------------------------------------------------------------------------
	"I hear that if you win, you get a free probe by aliens."
	--  Bill Coldwell, regarding the SETI@home project
(Courtesy of "Aaron J. Grier" <ag...@po...>)
--------------------------------------------------------------------------
William Stearns (wst...@po...).  Mason, Buildkernel, named2hosts, 
and ipfwadm2ipchains are at:                http://www.pobox.com/~wstearns
LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.com
--------------------------------------------------------------------------

[User-mode-linux-devel] Re: User-mode linux stack overflow: could be generic problem

[Jeff D. <jd...@ka...>]

> Program received signal SIGINT, Interrupt.
> 0x10007040 in panic (fmt=0x10120a80 "Stack overflowed onto current_task
>     at panic.c:100
> 100             for(;;) {
> (gdb)

That looks better.  Did you do anything different that time?

At this point, you supposed to do a 'bt' to see what's going on, and then
'return' you way up the stack, looking at $esp at each frame see see who's
eating up the stack.

> (gdb) att 1
> Attaching to program: /home/rendler/uml/linux, Pid 1
> 0x100b2fe1 in kill () at eth_kern.c:307
> 307     eth_kern.c: No such file or directory.

This still makes me a bit nervous.  I'm not sure where it's supposed to be when
it gets attached, but I don't think it's the ethernet driver.

				Jeff

[User-mode-linux-devel] Re: User-mode linux stack overflow: could be generic problem

[Robert R. <ip...@di...>]

I really have no idea what I'm doing.

180000e
att 1
b start_kernel
c
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and yo
welcome to change it and/or distribute copies of it under certain condi
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for deta
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) att 1
Attaching to program: /home/rendler/uml/linux, Pid 1
0x100b2fe1 in kill () at eth_kern.c:307
307     eth_kern.c: No such file or directory.
(gdb) b start_kernel
Breakpoint 1 at 0x100f37b9: file init/main.c, line 515.
(gdb) c
Continuing.

Breakpoint 1, start_kernel () at init/main.c:515
515             printk("Kernel command line: %s\n", saved_command_line)
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x10038490 in padzero (elf_bss=1073818712)
    at /usr/src/linux/include/asm/arch/string.h:418
418     /usr/src/linux/include/asm/arch/string.h: No such file or direc
(gdb) handle SIGSEGV pass nostop noprint
Signal        Stop      Print   Pass to program Description
SIGSEGV       No        No      Yes             Segmentation fault
(gdb) c
Continuing.

Program received signal SIGINT, Interrupt.
0x10007040 in panic (fmt=0x10120a80 "Stack overflowed onto current_task
    at panic.c:100
100             for(;;) {
(gdb)

-- 

"We are all so much together and yet we are all dying of loneliness."--A.Schweitzer

[User-mode-linux-devel] Re: User-mode linux stack overflow: could be generic problem

[Robert R. <ip...@di...>]

Sorry about that I totally forgot I stripped it.

140000e
att 1
b start_kernel
c
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) att 1
Attaching to program: /home/rendler/uml/linux, Pid 1
0x100b2fe1 in kill () at eth_kern.c:307
307             }
(gdb) b start_kernel
Breakpoint 1 at 0x100f37b9: file init/main.c, line 515.
(gdb) c
Continuing.
Breakpoint 1, start_kernel () at init/main.c:515
515             setup_arch(&command_line);
(gdb) handle SIGSEGV pass nostop noprint
Signal        Stop      Print   Pass to program Description
SIGSEGV       No        No      Yes             Segmentation fault
(gdb) c
Continuing.
warning: Couldn't get registers.
warning: Couldn't get registers.
warning: Couldn't get registers.
ptrace: Operation not permitted.
warning: Couldn't get registers.
warning: Couldn't get registers.
warning: Couldn't get registers.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0x100b2f64 in sigprocmask () at eth_kern.c:307
307             }
(gdb)  

-- 

"We are all so much together and yet we are all dying of loneliness."--A.Schweitzer

[User-mode-linux-devel] Re: [User-mode-linux-user] Re: User-mode linux stack overflow: could

[David C. <tec...@li...>]

On Tue, 10 Oct 2000, Jeff Dike wrote:
> Anyway, that particular patch is no great prize.  Is there some reason
> you particularly want it?

Didn't know it didn't work until after I tried it, e-mailed, then decided
to read the rest of the list mail :/


-- 
David Coulson
tec...@so...

[User-mode-linux-devel] Re: [User-mode-linux-user] Re: User-mode linux stack overflow: could

[Jeff D. <jd...@ka...>]

> I tried to apply that patch to a checkout of the uml code from cvs, and it
> failed.
> 
> Either it has been applied (doesn't look like it) to the code which is in
> cvs already, or I'm doing something stupid.

It's not in CVS.  It might be relative to one of the other patches
I've been floating around.  That would be my guess.

Anyway, that particular patch is no great prize.  Is there some reason
you particularly want it?

I'm going to release that change in test10, but just as cleanup.  I've
banged on it and it seems fine, and it reduces stack usage a little,
but it doesn't really fix anyone's problems.

				Jeff

[User-mode-linux-devel] Re: [User-mode-linux-user] Re: User-mode linux stack overflow: could be generic problem

[David C. <tec...@li...>]

On Sun, 8 Oct 2000, Jeff Dike wrote:
> Anyway, the patch below removes 256 bytes from the set_signals frame.  It
> ought to alleviate things a bit.  I'll be looking for other things I can do,
> as well. Let me know how it works for you.

I tried to apply that patch to a checkout of the uml code from cvs, and it
failed.

Either it has been applied (doesn't look like it) to the code which is in
cvs already, or I'm doing something stupid.

Ideas?

-- 
David Coulson
tec...@so...

Re: [User-mode-linux-devel] Re: User-mode linux stack overflow: could be generic problem

[Jeff D. <jd...@ka...>]

Are you sure that gdb is debugging the right binary and it has symbols (i.e. 
when gdb says "attaching to ..." the "..." is the linux that you're running)?

ip...@di... said:
> 0x10038490 in ?? () 

This sort of suggests that gdb is basically confused about what it's looking 
at.

					Jeff

[User-mode-linux-devel] Re: User-mode linux stack overflow: could be generic problem

[Robert R. <ip...@di...>]

I have no idea if this is how you do it but anyways.

Program received signal SIGSEGV, Segmentation fault.
0x10038490 in ?? ()
(gdb) handle SIGSEGV pass nostop noprint
Signal        Stop      Print   Pass to program Description
SIGSEGV       No        No      Yes             Segmentation fault
(gdb) continue
Continuing.
warning: Couldn't get registers.
warning: Couldn't get registers.
warning: Couldn't get registers.
ptrace: Operation not permitted.
warning: Couldn't get registers.
warning: Couldn't get registers.
warning: Couldn't get registers.
0x100b2744 in ?? ()
(gdb)

-- 

"We are all so much together and yet we are all dying of loneliness."--A.Schweitzer

[User-mode-linux-devel] Re: User-mode linux stack overflow: could be generic problem

[Jeremy F. <je...@go...>]

On Sun, Oct 08, 2000 at 12:35:48AM -0500, Jeff Dike wrote:
> I've been waiting for someone to send me that stack.  There aren't any real 
> smoking guns there.  I'm guessing that the difference between your laptop and 
> the machine it works on is that your laptop is running a fairly recent kernel 
> (2.4.0-testx) and the other isn't.

Yep, that's right.

> The sigcontext struct greatly increased in 
> size (to ~800 bytes IIRC) to accomodate the MMX registers or something.  There 
> are three signals on your stack, so those frames by themselves are taking up 
> half the stack page.
> 
> Anyway, the patch below removes 256 bytes from the set_signals frame.  It 
> ought to alleviate things a bit.  I'll be looking for other things I can do, 
> as well. Let me know how it works for you.

I'm afraid this doesn't help.  The stack still overflows at the same point.
It looks like each signal frame is ~760 bytes.  Even with this patch, the
overflow is 808 bytes (without the patch it's 1232 bytes).

	J

[User-mode-linux-devel] Re: User-mode linux stack overflow: could be generic problem

[Jeff D. <jd...@ka...>]

Thank you!

I've been waiting for someone to send me that stack.  There aren't any real 
smoking guns there.  I'm guessing that the difference between your laptop and 
the machine it works on is that your laptop is running a fairly recent kernel 
(2.4.0-testx) and the other isn't.  The sigcontext struct greatly increased in 
size (to ~800 bytes IIRC) to accomodate the MMX registers or something.  There 
are three signals on your stack, so those frames by themselves are taking up 
half the stack page.

Anyway, the patch below removes 256 bytes from the set_signals frame.  It 
ought to alleviate things a bit.  I'll be looking for other things I can do, 
as well. Let me know how it works for you.

				Jeff

--- arch/um/kernel/signal_user.c~       Thu Sep 14 17:00:08 2000
+++ arch/um/kernel/signal_user.c        Sun Oct  8 00:21:29 2000
@@ -45,26 +45,29 @@
 
 int set_signals(int enable)
 {
-       sigset_t mask, unmask, old;
+       sigset_t mask;
+       int ret;
 
        check_stack_overflow(&enable);
+       sigprocmask(SIG_BLOCK, NULL, &mask);
+       ret = enable_mask(&mask);
        sigemptyset(&mask);
-       sigemptyset(&unmask);
-       if(enable & (1 << SIGIO_BIT)) sigaddset(&unmask, SIGIO);
-       else sigaddset(&mask, SIGIO);
+       if(enable & (1 << SIGIO_BIT)) sigaddset(&mask, SIGIO);
        if(enable & (1 << SIGVTALRM_BIT)){
-               sigaddset(&unmask, SIGVTALRM);
-               sigaddset(&unmask, SIGALRM);
+               sigaddset(&mask, SIGVTALRM);
+               sigaddset(&mask, SIGALRM);
        }
-       else {
+       if(sigprocmask(SIG_UNBLOCK, &mask, NULL) < 0)
+               panic("Failed to enable signals");
+       sigemptyset(&mask);
+       if((enable & (1 << SIGIO_BIT)) == 0) sigaddset(&mask, SIGIO);
+       if((enable & (1 << SIGVTALRM_BIT)) == 0){
                sigaddset(&mask, SIGVTALRM);
                sigaddset(&mask, SIGALRM);
        }
-       if(sigprocmask(SIG_BLOCK, &mask, &old) < 0)
-               panic("Failed to change signal mask");
-       if(sigprocmask(SIG_UNBLOCK, &unmask, NULL) < 0)
-               panic("Failed to change signal mask");
-       return(enable_mask(&old));
+       if(sigprocmask(SIG_BLOCK, &mask, NULL) < 0)
+               panic("Failed to block signals");
+       return(ret);
 }
 
 /*

[User-mode-linux-devel] Kernel panic: Stack overflowed onto current_task page

[Jeff D. <jd...@ka...>]

I looked into this a bit, and I found that devfs is putting a 3K structure on 
the stack, which seems bad to me.  I complained at Richard Gooch about it.

In the meantime, if you're seeing this problem (especially at boot time) apply 
the patch below.

There is still a problem with interrupts causing stack overflows which I'm 
trying to track down, but this patch provides some extra room for people who 
aren't triggering that bug.

				Jeff

--- arch/um/kernel/process_kern.c~      Mon Sep 25 15:34:25 2000
+++ arch/um/kernel/process_kern.c       Fri Oct  6 12:07:28 2000
@@ -711,8 +711,13 @@
 
 void check_stack_overflow(void *ptr)
 {
-       if((((unsigned long) ptr) & PAGE_MASK) == (unsigned long) current)
-               panic("Stack overflowed onto current_task page");
+       unsigned long addr, c;
+
+       addr = (unsigned long) ptr;
+       c = (unsigned long) current;
+
+       if(addr - c < PAGE_SIZE / 2)
+               panic("Stack overflowed well into the current_task page");
 }
 
 int singlestepping(void *t)

Re: [User-mode-linux-devel] test9 - success/failure?

[Jeff D. <jd...@ka...>]

jl...@mi... said:
> I compiled my own and am tring to run it on a native 2.4.0-test8 with
> no luck.  signal 11 when trying to mount disk. 

test8 is a known bad host.  Someone broke ptrace.  test7 and test9 are both 
good hosts.

				Jeff

Re: [User-mode-linux-devel] test9 - success/failure?

[James R. L. <jl...@mi...>]

On Wed, Oct 04, 2000 at 04:32:53PM -0400, William Stearns wrote:
> Good day, all,
> 	I'd like to get feedback on whether Jeff's test9 kernel boots for
> anyone at all.  Could you send me success/failure reports (privately,
> please!  I'll summarize to the list.)  Please include the host kernel
> version and whether you're using Jeff's stock kernel or your own.
> 	Cheers,
> 	- Bill

I compiled my own and am tring to run it on a native 2.4.0-test8 with no
luck.  signal 11 when trying to mount disk.

Jim
-- 
James R. Leu

[User-mode-linux-devel] Re: test9 - finally some action on stack_check_overflow!

[Jeff D. <jd...@ka...>]

Can you apply the patch below and do the stack overflow thing again?  Do it 
like you did before except without the "handle SIGSEGV..".

Also make sure that when it says "Attaching to program: 
/home/wstearns/uml/rh6.2/linux, Pid 1", the executable it names is the one 
that you're actually running.

And make sure that it has symbols in it.  This sort of suggests that it didn't:
(gdb) b start_kernel
No symbol table is loaded.  Use the "file" command.

I think one of these is what caused your problems last time.  When you see 
things like:
0x10038fbd in ?? ()
it usually means that gdb is getting symbols from the wrong executable or it's 
not getting symbols at all.  I think that also explains this stuff:

warning: Couldn't get registers.
warning: Couldn't get registers.
warning: Couldn't get registers.
#0  0x100a96dd in ?? ()
Error accessing memory address 0x5005332c: No such process.

				Jeff

--- arch/um/kernel/trap_user.c~ Mon Sep 25 17:04:54 2000
+++ arch/um/kernel/trap_user.c  Thu Oct  5 11:16:31 2000
@@ -208,6 +208,7 @@
                                }
                                break;
                        case SIGCONT:
+                       case SIGSEGV:
                                break;
                        default:
                                if(debugger_pid != -1){

Re: [User-mode-linux-devel] test9 - success/failure?

[Jeff D. <jd...@ka...>]

wst...@po... said:
> I'd like to get feedback on whether Jeff's test9 kernel boots for
> anyone at all.

It Works For Me (TM)

			Jeff :-)

[User-mode-linux-devel] test9 - success/failure?

[William S. <wst...@po...>]

Good day, all,
	I'd like to get feedback on whether Jeff's test9 kernel boots for
anyone at all.  Could you send me success/failure reports (privately,
please!  I'll summarize to the list.)  Please include the host kernel
version and whether you're using Jeff's stock kernel or your own.
	Cheers,
	- Bill

---------------------------------------------------------------------------
	The dyslexic, agnostic, insomniac lay in his bed awake all night
wondering if there is a doG.
(Courtesy of Miquel van Smoorenburg <mi...@ci...>)
--------------------------------------------------------------------------
William Stearns (wst...@po...).  Mason, Buildkernel, named2hosts, 
and ipfwadm2ipchains are at:                http://www.pobox.com/~wstearns
LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.com
--------------------------------------------------------------------------

[User-mode-linux-devel] Re: test9 - finally some action on stack_check_overflow!

[Jeff D. <jd...@ka...>]

One more thing - is the kernel that you're running 
'/home/wstearns/uml/rh6.2/linux'?

wst...@po... said:
> (gdb) att 1 
> Attaching to program: /home/wstearns/uml/rh6.2/linux, Pid 1 

gdb is somewhat simple-minded about the executable file that it uses for 
symbols.  If it finds a 'linux' in your current directory, it will use it, 
even if you're running a linux from somewhere else.

The reason that I'm asking is that the stack that you got is complete 
gibberish.

				Jeff

[User-mode-linux-devel] Re: test9 - finally some action on stack_check_overflow!

[Jeff D. <jd...@ka...>]

That wasn't it.  You need to see panic on the stack.

Before you continue the kernel do:
	handle SIGSEGV pass nostop noprint

				Jeff

[User-mode-linux-devel] Re: test9 - finally some action on stack_check_overflow!

[William S. <wst...@po...>]

On Wed, 4 Oct 2000, Jeff Dike wrote:

> wst...@po... said:
> > VFS: Mounted root (ext2 filesystem) readonly. 
> > Mounted devfs on /dev
> > INIT: version 2.78 booting 
> > Kernel panic: Stack overflowed onto current_task page from set_signals 
> 
> I need a stack trace from the panicing thread, not the tracing thread.
> 
> Put 'debug' on the command line, and when it panics, ^C and get the backtrace.

	Hmm, after all the work you put into debugging tools, wouldn't it
be nice if your users actually _used_ them?  *grin*
	Here it is - it's from my debug kernel.

b00000e
att 1
b start_kernel
c
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(gdb) att 1
Attaching to program: /home/wstearns/uml/rh6.2/linux, Pid 1
0x100a9711 in __default_morecore (increment=27134)
    at ../sysdeps/generic/morecore.c:48
48      ../sysdeps/generic/morecore.c: No such file or directory.
(gdb) b start_kernel
Breakpoint 1 at 0x100e4b8c: file init/main.c, line 505.
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x10038fbd in add_gd_partition (hd=0x40013994, minor=18, start=1343099424, 
    size=96) at check.c:175
175             hd->part[minor].start_sect = start;
(gdb) bt
#0  0x10038fbd in add_gd_partition (hd=0x40013994, minor=18,
start=1343099424, 
    size=96) at check.c:175
#1  0x50053c40 in ?? ()
#2  0x10039a76 in msdos_partition (hd=0x50053d18, dev=1343086976, 
    first_sector=1342520512, first_part_minor=1342524448) at msdos.c:480
#3  0x1003a352 in ext2_new_block (inode=0x50053df8, goal=0, 
    prealloc_count=0x50053de0, prealloc_block=0x1002824a, err=0xffffffff)
    at
/usr/src/uml-linux/linux-2.4.0-test8.uml/include/asm/arch/string.h:552
#4  0x10028d40 in sys_mknod (filename=0x50053df8 "\177ELF\001\001\001", 
    mode=0, dev=20485) at namei.c:1214
#5  0x10028f38 in d_unhash (dentry=0x100fae6d) at namei.c:1307
#6  0x1009e221 in tracing_cb (proc=0x100fae6d <tvecs+38221>,
arg=0x1012a140)
    at process_kern.c:301
#7  0x1009e264 in do_proc_op (t=0x100fae6d, proc_id=269656384)
    at process_kern.c:324
#8  0x10001395 in flush_signals (t=0x0) at signal.c:108
#9  0x100a3a02 in sigaddset (set=0x50052000, signo=0) at sigaddset.c:29
(gdb) bt
#0  0x10038fbd in add_gd_partition (hd=0x40013994, minor=18,
start=1343099424, 
    size=96) at check.c:175
#1  0x50053c40 in ?? ()
#2  0x10039a76 in msdos_partition (hd=0x50053d18, dev=1343086976, 
    first_sector=1342520512, first_part_minor=1342524448) at msdos.c:480
#3  0x1003a352 in ext2_new_block (inode=0x50053df8, goal=0, 
    prealloc_count=0x50053de0, prealloc_block=0x1002824a, err=0xffffffff)
    at
/usr/src/uml-linux/linux-2.4.0-test8.uml/include/asm/arch/string.h:552
#4  0x10028d40 in sys_mknod (filename=0x50053df8 "\177ELF\001\001\001", 
    mode=0, dev=20485) at namei.c:1214
#5  0x10028f38 in d_unhash (dentry=0x100fae6d) at namei.c:1307
#6  0x1009e221 in tracing_cb (proc=0x100fae6d <tvecs+38221>,
arg=0x1012a140)
    at process_kern.c:301
#7  0x1009e264 in do_proc_op (t=0x100fae6d, proc_id=269656384)
    at process_kern.c:324
#8  0x10001395 in flush_signals (t=0x0) at signal.c:108
#9  0x100a3a02 in sigaddset (set=0x50052000, signo=0) at sigaddset.c:29
(gdb) 

	Cheers,
	- Bill

---------------------------------------------------------------------------
	"Usenet is like a herd of performing elephants with diarrhea;
massive, difficult to redirect, awe-inspiring, entertaining, and a source
of mind-boggling amounts of excrement when you least expect it." 
	-- Anon
(Courtesy of someone at Redhat, perhaps Elliot Lee?)
--------------------------------------------------------------------------
William Stearns (wst...@po...).  Mason, Buildkernel, named2hosts, 
and ipfwadm2ipchains are at:                http://www.pobox.com/~wstearns
LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.com
--------------------------------------------------------------------------

[User-mode-linux-devel] Re: test9 - finally some action on stack_check_overflow!

[Jeff D. <jd...@ka...>]

wst...@po... said:
> VFS: Mounted root (ext2 filesystem) readonly. 
> Mounted devfs on /dev
> INIT: version 2.78 booting 
> Kernel panic: Stack overflowed onto current_task page from set_signals 

I need a stack trace from the panicing thread, not the tracing thread.

Put 'debug' on the command line, and when it panics, ^C and get the backtrace.

				Jeff

[User-mode-linux-devel] test9 - finally some action on stack_check_overflow!

[William S. <wst...@po...>]

Good evening, Jeff,

On Tue, 3 Oct 2000, Jeff Dike wrote:

> Only test9 updates this time.  Everything else was already checked in.

	Thanks again for all your work on UML, Jeff!
	I'm finally getting some information back from
stack_check_overflow:

VFS: Mounted root (ext2 filesystem) readonly.
Mounted devfs on /dev
INIT: version 2.78 booting
Kernel panic: Stack overflowed onto current_task page from set_signals

	I get this at every single boot, followed about 50% of the time
by:

In interrupt handler - not syncing

	A quick patch shows where stack_check_overflow was called
from; in this case from set_signals.
	
	The only two calls in the uml patch to set_signals are:

#define local_irq_save(flags) do { (flags) = set_signals(0); } while(0)
#define local_irq_restore(flags) do { set_signals(flags); } while(0)

	, which are respectively used in the save_flags and restore_flags
macros.  Only used about 2200 and 3300 times, respectively, in the main
kernel.  *grin/sigh*

23485 pts/19   S      0:00      \_ ./linux-2.4.0-test9-sodebug [(tracing thread)
...
23494 pts/19   T      0:00          \_ ./linux-2.4.0-test9-sodebug [init]

	GDB:

[root@sparrow rh6.2]# gdb linux-2.4.0-test9-sodebug
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) att 23485
Attaching to program: /home/wstearns/uml/rh6.2/linux-2.4.0-test9-sodebug, Pid 23485
0x100b1599 in __wait4 ()
(gdb) p current_task.pid
$1 = 7
(gdb) p current_task.prev_task.comm
$2 = "init\000er\000\000\000\000\000\000\000\000"
(gdb) p current_task.prev_task.thread
$3 = {extern_pid = 23494, tracing = 0, forking = 0, kernel_stack = 1343741952, real_mm = 0x50054b60, starting_exec = 0, signal = {signal = 0, sp = 0, handler = 0},
  npending = 0, saved_sigs = {sig = {0, 0}}, nsyscalls = 16, process_regs = {regs = {7, 3212835004, 0, 0, 7, 3212834952, 4294967258, 43, 43, 0, 0,  114, 1074441865,
      35, 518, 3212834920, 43}}, syscall_regs = {regs = {23494, 19, 23494, 1342513804, 1342513152, 1343749404, 0, 43, 43, 0, 0, 37, 269129489, 35, 519, 1343749312,
      43}}, syscall_stack = 0x50178000, syscall_stack_size = 832, altstack_regs = {regs = {0 <repeats 17 times>}}, altstack = 0x0, altstack_size = 0, cr2 = 0,
  err = 0, check_sigs = 0, restore_state = 0, mm_changes = 0, fault_addr = 0x0, syscall = {id = 114, args = {7, 3212835004, 0, 0, 7, 3212834952}, have_result = 0,
    result = 0, again = 0}, request = {op = 0, u = {exec = {ip = 1343553536, sp = 1343537152}, fork = {task = 0x50150000, tramp_stack = 1343537152, sp = 0},
      cswitch = {to = 0x50150000, from = 0x5014c000}, thread = {proc = 0x50150000, arg = 0x5014c000, flags = 0, new_pid = -1082132144, new_task = 0xbf7ff950,
        cpu = 0}, fork_finish = {stack = 1343553536, regs = {regs = {1343537152, 0, 3212835152, 3212835152, 0, 3212835664, 0, 43, 43, 0, 0, 2, 1074442807, 35, 518,
            3212834944, 43}}, from = 0x50052000}, cb = {proc = 0x50150000, arg = 0x5014c000}}}}
(gdb) bt
#0  0x100b1599 in __wait4 ()
#1  0x7 in ?? ()
#2  0x100a2501 in signals (init_proc=0x100a29b8 <start_kernel_proc>, sp=0x10129ffc) at trap_user.c:98
#3  0x100a2e80 in linux_main (argc=2, argv=0xbffff704) at um_arch.c:189
#4  0x100012a4 in main (argc=2, argv=0xbffff704, envp=0xbffff710) at /usr/src/uml-linux/linux-2.4.0-test9.uml/arch/um/main.c:66
#5  0x100a9411 in __libc_start_main (main=0x100010dc <main>, argc=2, ubp_av=0xbffff704, init=0x100000b4 <_init>, fini=0x100fa958 <_fini>, rtld_fini=0,
    stack_end=0xbffff6fc) at ../sysdeps/generic/libc-start.c:111
(gdb) quit
The program is running.  Quit anyway (and detach it)? (y or n) y
Detaching from
program: /home/wstearns/uml/rh6.2/linux-2.4.0-test9-sodebug, Pid 23485
[root@sparrow rh6.2]# 

	Cheers,
	- Bill

Host kernel is 2.4.0-test9-pre8.  (Host was upgraded to RH 7.0, but I
don't think that's related; even with the new host OS, uml still starts
just fine on Jeff's stock test8 kernel.)

---------------------------------------------------------------------------
	"I hear that if you win, you get a free probe by aliens."
	--  Bill Coldwell, regarding the SETI@home project
(Courtesy of "Aaron J. Grier" <ag...@po...>)
--------------------------------------------------------------------------
William Stearns (wst...@po...).  Mason, Buildkernel, named2hosts, 
and ipfwadm2ipchains are at:                http://www.pobox.com/~wstearns
LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.com
--------------------------------------------------------------------------

[User-mode-linux-devel] test9 is checked in

[Jeff D. <jd...@ka...>]

Only test9 updates this time.  Everything else was already checked in.

				Jeff