Hi,
this is a bit more debugging info on the glibc 2.3 release (I will try the
latest version soon, I just want to send this as long as I am still able to
reproduce it). I don't really know how to make sense of this. I spotted
that main_arena's next pointer is zero, while the code assumes that the list
is circular.
When I started to stepi through the code, it first took the list lock, then
the main arena's mutex, and then it got:
(gdb) stepi
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x010ecd79 in ptmalloc_lock_all () at ../sysdeps/mach/i386/machine-lock.h:52
52 __asm__ __volatile ("xchgl %0, %1"
when trying to lock main_arena.next (which was 0).
When leaving gdb at that point, the sh process (which forked), still runs.
And after I few seconds I get a kernel panic. This seems to be another bug.
(See below for a kernel backtrace, which looks ok to me).
I will set a breakpoint at the exception handler and see if that shows
something (an infinite amount of exceptions generated or something like
that).
Thanks,
Marcus
#0 0x0016d2a3 in panic ()
No symbol table info available.
#1 0x001178b8 in zalloc (zone=0x303368a0) at ../gnumach/kern/zalloc.c:489
addr = 0
#2 0x0010601a in ipc_port_alloc_special (space=0x30336934) at
../gnumach/ipc/ipc_port.c:1253
port = (struct ipc_port *) 0x30ac5d10
#3 0x0010e32c in exception_raise (dest_port=0x30de2448, thread_port=0x30a7a0bc,
task_port=0x30a6e3cc, _exception=1, code=2, subcode=0) at
../gnumach/kern/exception.c:382
self = (struct thread *) 0x30ac5d10
receiver = (struct thread *) 0x31f3bed0
reply_port = (struct ipc_port *) 0x0
dest_mqueue = (struct ipc_mqueue *) 0x30aa924c
reply_mqueue = (struct ipc_mqueue *) 0x309bc010
kmsg = (struct ipc_kmsg *) 0x30aa924c
mr = 816602384
#4 0x0010e224 in exception_try_task (_exception=1, code=2, subcode=0) at
../gnumach/kern/exception.c:213
self = (struct thread *) 0x30ac5d10
task = (struct task *) 0x0
exc_port = (struct ipc_port *) 0x30de2448
#5 0x0010e162 in exception (_exception=0, code=808674744, subcode=0) at
../gnumach/kern/exception.c:123
self = (struct thread *) 0x30ac5d10
exc_port = (struct ipc_port *) 0x0
#6 0x00135755 in i386_exception (exc=1, code=2, subcode=0) at
../gnumach/i386/i386/trap.c:1007
s = 0
#7 0x00134d78 in user_page_fault_continue (kr=2) at ../gnumach/i386/i386/trap.c:117
thread = (struct thread *) 0x0
regs = (struct trap_state *) 0x30ac5e9c
#8 0x0011a972 in vm_fault (map=0x30a5e02c, vaddr=0, fault_type=3, change_wiring=0,
resume=0,
continuation=0x134d4e <user_page_fault_continue>) at ../gnumach/vm/vm_fault.c:1517
version = {main_timestamp = 1780800}
wired = 838057900
object = (struct vm_object *) 0x30ac9378
offset = 1276736
prot = 1127928
old_copy_object = (struct vm_object *) 0x1134f4
result_page = (struct vm_page *) 0x30ac9378
top_page = (struct vm_page *) 0x137b40
kr = 2
m = (struct vm_page *) 0x30ac5d10
#9 0x001351ba in user_trap (regs=0x30ac5e9c) at ../gnumach/i386/i386/trap.c:472
exc = 815513600
code = 0
subcode = 0
type = 14
thread = (struct thread *) 0x30ac5d10
here is some more info:
(gdb) up
#1 0x001178b8 in zalloc (zone=0x303368a0) at ../gnumach/kern/zalloc.c:489
489 panic("zalloc: zone %s exhausted",
(gdb) l
484 zone_lock(zone);
485 REMOVE_FROM_ZONE(zone, addr, vm_offset_t);
486 } else {
487 addr = zget_space(zone->elem_size);
488 if (addr == 0)
489 panic("zalloc: zone %s exhausted",
490 zone->zone_name);
491
492 zone_lock(zone);
493 zone_count_up(zone);
(gdb) print *zone
$4 = {free_elements = 0, cur_size = 8005384, max_size = 11847168, elem_size = 76,
alloc_size = 4096, doing_alloc = 0, zone_name = 0x18915d "ipc ports", type = 0,
complex_lock = {
thread = 0x0, read_count = 0, want_upgrade = 0, want_write = 0, waiting = 0,
can_sleep = 0,
recursion_depth = 0}, next_zone = 0x303368cc}
--
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org [EMAIL PROTECTED]
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de/
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
