Re: New oskit-mach debugging log - failed assertion 'port->ip_srights > 0'
On Sun, Mar 10, 2002 at 09:43:27PM -0500, B. Douglas Hilton wrote:
> Through the use of breakpoints, I found that it
> fails the *third* time it runs through this function,
> when it attempts to execute:
>
> 1126 assert(port->ip_srights > 0);
Ok, so there is a bug in the boot script cleanup handler. It should
probably be more helpful. ;)
> module 0: /hurd/ext2fs.static
> --multiboot-command-line=${kernel-command-line}
> --host-priv-port=${host-port} --device-master-port=${device-port}
> --exec-server-task=${exec-task} -T typed ${root} $(task-create)
> $(task-resume) module 1: /lib/ld.so.1 /hurd/exec $(exec-task=task-create)
> 2 multiboot modules
You are using the less tested new method of booting. As a work around, you
might want to try to use the old serverboot method of booting. But please
keep on track of this problem, so we can fix it! (We want to get rid of
serverboot asap). Dig out any of the older installation instructions how to
boot with serverboot.
The interesting part for me is not so much why the assertion fails, but why
you get into the cleanup handler with ABORTING == 1 (see frame #5)
> (gdb) bt full
> #0 0x0010a87a in ipc_port_release_send (port=0xc0d28d4) at
> ../hurd-20020103/oskit-mach/ipc/ipc_port.c:1126
> nsrequest = 0x0
> mscount = 202188136
> #1 0x0011cded in ipc_task_terminate (task=0xc0d2720) at
> ../hurd-20020103/oskit-mach/kern/ipc_tt.c:188
> kport = 0xc0d28d4
> i = 0
> #2 0x00123bd1 in task_terminate (task=0xc0d2720) at
> ../hurd-20020103/oskit-mach/kern/task.c:426
> task = 0xc0d2720
> thread = 0xc0d2a67
> cur_thread = 0xc0d06f8
> list = (queue_head_t *) 0xc0d2738
> cur_task = 0xc0d04c8
> s = 0
> #3 0x0011921c in boot_script_free_task (task=0xc0d2720, aborting=1) at
> ../hurd-20020103/oskit-mach/kern/bootstrap.c:815
> No locals.
> #4 0x001280b6 in free_cmd (cmd=0xc0d26b0, aborting=1) at
> ../hurd-20020103/oskit-mach/kern/boot_script.c:109
> No locals.
> #5 0x001281a2 in cleanup (aborting=1) at
> ../hurd-20020103/oskit-mach/kern/boot_script.c:131
> i = 1
> #6 0x00129020 in boot_script_exec () at
> ../hurd-20020103/oskit-mach/kern/boot_script.c:632
> argv = (char **) 0xc0d29a0
> cmdline = 0xc0d29e0 ""
> i = 0
> argc = 7
> cmdline_alloc = 230
> cmdline_index = 141
> error = 5
error 5 is (kern/boot_script.h):
#define BOOT_SCRIPT_UNDEF_SYM 5
We should use an enum here so it is more apparent. So it hit an undefined symbol
in boot_script_exec, line 560, which means it could not resolve a variable.
Set a break point at that line and see what ARG, SYM etc look like (eg where
in the boot script parsing it fails).
Somehow it doesn't like your GRUB boot configuration. You should be able to
find out what it is and how to fix it, but you should also try to fix the
other, deeper problem so other users get a more helpful response than an
instant kernel reboot ;)
Thanks!
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: