Re: veriexecctl(8) segfaults when no argument is given

["Stathis Kamperis" <ekamperi%gmail.com@localhost>]

2008/9/6, Brett Lymn <blymn%baesystems.com.au@localhost>:
> On Thu, Sep 04, 2008 at 09:35:32PM +0300, Stathis Kamperis wrote:
>  >
>  > I've built a kernel with LOCKDEBUG enabled and here is the panic along
>  > with the backtrace.
>  > http://stathisk.ath.cx/028se1.jpg
>  >
>  > (Note that without LOCKDEBUG I was able to start X and I had to run
>  > veriexecctl in order to reproduce the problem.)
>  >
>
>
> Hmmm that is not very illuminating.  Have you tried to get a crash
>  dump?
>
>  Also, is this a multiprocessor machine?  If so, what is the backtrace
>  on the second cpu? (use mach cpu 1 to change to cpu 1).
>

I got a kernel crash dump and here is what gdb says about:


[stathis@netbsd ~] su
Password:
# gdb /netbsd-debug.gdb
GNU gdb 6.5
Copyright (C) 2006 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--netbsdelf"...
(gdb) target kvm /var/crash/netbsd.0.core
#0  0xc05a4b52 in cpu_reboot (howto=260, bootstr=0x0)
    at /usr/src/sys/arch/i386/i386/machdep.c:883
883                     dumpsys();
(gdb) bt
#0  0xc05a4b52 in cpu_reboot (howto=260, bootstr=0x0)
    at /usr/src/sys/arch/i386/i386/machdep.c:883
#1  0xc01de298 in db_reboot_cmd (addr=-1061806035, have_addr=false,
    count=-1061806048, modif=0xcbc6ea00 "0êÆË+ ¶À, ¶À4")
    at /usr/src/sys/ddb/db_command.c:1318
#2  0xc01ddda8 in db_command (last_cmdp=0xc0ae23bc)
    at /usr/src/sys/ddb/db_command.c:933
#3  0xc01de0f2 in db_command_loop () at /usr/src/sys/ddb/db_command.c:578
#4  0xc01e1000 in db_trap (type=1, code=0) at /usr/src/sys/ddb/db_trap.c:101
#5  0xc059fb0b in kdb_trap (type=1, code=0, regs=0xcbc6ec2c)
    at /usr/src/sys/arch/i386/i386/db_interface.c:229
#6  0xc05a7933 in trap (frame=0xcbc6ec2c)
    at /usr/src/sys/arch/i386/i386/trap.c:352
#7  0xc010cc76 in calltrap ()
#8  0xc059e22c in breakpoint ()
#9  0xc04d7388 in panic (
    fmt=0xc0a8261c "lockdebug_barrier: holding %d shared locks")
    at /usr/src/sys/kern/subr_prf.c:255
#10 0xc04d03b1 in lockdebug_barrier (spinlock=0x0, slplocks=0)
    at /usr/src/sys/kern/subr_lockdebug.c:664
#11 0xc05a72a3 in syscall (frame=0xcbc6ed48) at /usr/src/sys/sys/userret.h:102
#12 0xc010057d in syscall1 ()
(gdb)

My system is UP with an Intel Pentium 4 at 2Ghz, 512 MB RAM, 40 GB IDE
disk and no exotic hardware attached to it. I am running 4.99.72/i386
with wapbl enabled.

Is there anything else I could do to gather more clues regarding the crash ?

Best regards,
Stathis Kamperis