Re: crash in amd64 -current

2021-01-22 Thread Paul Goyette

On Fri, 22 Jan 2021, Christos Zoulas wrote:


In article ,
Paul Goyette   wrote:

With sources updated a few hours ago (2021-01-21 at 17:17:48 UTC) I am
getting the following crash as soon as it tries to start syslogd:



Also, why the heck does savecore(8) complain when I use the -N option?

# savecore -fN /netbsd.bad.gdb
savecore: dumpdev /dev/console is tty; override kernel


Seems that the dump device it finds by reading the kernel namelist
from /netbsd.bad.gdb ends up being /dev/console...
Is the machine you are running gdb the same as the machine that produced
the dump? because the dev_t it read from the kernel namelist matched the
dev_t for the console on the local machine in /dev.


Same machine.  The dump was produced by a ddb ``sync'' command from a
9.99.78 kernel, and savecore(8) was running on a 9.99.77 kernel-plus-
userland;  that's why I specified the -N.

It seems that savecore actually copied some info correctly without the
-N option, and crash(8) was able to get a stack-trace.  But gdb(1) was
unable to provide a stack trace.

This is with a custom kernel, with many device drivers loaded at run-
time.


++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: crash in amd64 -current

2021-01-21 Thread Christos Zoulas
In article ,
Paul Goyette   wrote:
>With sources updated a few hours ago (2021-01-21 at 17:17:48 UTC) I am
>getting the following crash as soon as it tries to start syslogd:
>
>   breakpoint() at breakpoint+0x5
>   vpanic() at vpanic+0x156
>   snprintf() at snprintf
>   kqueue_check() at kqueue_check+0x183
>   kevent1() at kevent1+0x49f
>   sys___kevent50() at sys___kevent50+0x33
>   syscall() at syscall+0x23e
>   --- syscall (number 435) ---
>   syscall+0x23e:
>
>Also, why the heck does savecore(8) complain when I use the -N option?
>
>   # savecore -fN /netbsd.bad.gdb
>   savecore: dumpdev /dev/console is tty; override kernel

Seems that the dump device it finds by reading the kernel namelist
from /netbsd.bad.gdb ends up being /dev/console... 
Is the machine you are running gdb the same as the machine that produced
the dump? because the dev_t it read from the kernel namelist matched the
dev_t for the console on the local machine in /dev.

christos