Panic after update main-n269202-4e7aa03b7076 -> n269230-f6f67f58c19d

Discussion:

(too old to reply)

David Wolfskill

2024-04-09 11:47:07 UTC

Machine had been running:

FreeBSD 15.0-CURRENT #43 main-n269202-4e7aa03b7076: Mon Apr 8 11:19:58 UTC 2024 ***@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1500018 1500018

This was an in-place source update, after updating sources to
main-n269230-f6f67f58c19d. On reboot (after "make installworld"
completed, I see this on the serial console (copy/pasted):

...
Starting lockd.

Fatal trap 12: page fault while in kernel mode
cpuid = 9; apic id = 09
fault virtual address = 0x18
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80b208c5
stack pointer = 0x28:0xfffffe048c204920
frame pointer = 0x28:0xfffffe048c204960
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 1208 (rpc.Starting automountd.
lockd)
rdi: 0000000000000000 rsi: fffff801078b0740 rdx: 0000000000000000
rcx: 000000000000010a r8: ffffffff818d30f0 r9: 0000000000000000
rax: 0000000000000000 rbx: 00000000Starting powerd.00000018 rbp: fffffe048c204960
r10: 0000000000010000 r11: 0000000000000001 r12: fffff80274e32c18
r13: 000000000000010a r14: fffff80274e32c00 r15: ffffffff812ae38a
trap number = 12
panic: page fault
cpuid = 9
time = 1712662362
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe048c2045f0
vpanic() at vpanic+0x135/frame 0xfffffe048c204720
panic() at panic+0x43/frame 0xfffffe048c204780
trap_fatal() at trap_fatal+0x40b/frame 0xfffffe048c2047e0
trap_pfault() at trap_pfault+0xa0/frame 0xfffffe048c204850
calltrap() at calltrap+0x8/frame 0xfffffe048c204850
--- trap 0xc, rip = 0xffffffff80b208c5, rsp = 0xfffffe048c204920, rbp = 0xfffffe
048c204960 ---
__mtx_lock_flags() at __mtx_lock_flags+0x45/frame 0xfffffe048c204960
clnt_vc_create() at clnt_vc_create+0x4f4/frame 0xfffffe048c204ab0
local_rpcb() at local_rpcb+0x11b/frame 0xfffffe048c204b50
rpcb_unset() at rpcb_unset+0x24/frame 0xfffffe048c204bb0
svc_tp_create() at svc_tp_create+0xee/frame 0xfffffe048c204c90
sys_nlm_syscall() at sys_nlm_syscall+0x3d0/frame 0xfffffe048c204e00
amd64_syscall() at amd64_syscall+0x158/frame 0xfffffe048c204f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe048c204f30
--- syscall (154, FreeBSD ELF64, nlm_syscall), rip = 0x3f00a2dfd2a, rsp = 0x3f00
96f7168, rbp = 0x3f0096f7230 ---
KDB: enter: panic
[ thread pid 1208 tid 101107 ]
Stopped at kdb_enter+0x33: movq $0,0x104eb92(%rip)
db>

Given suitable clues, I can poke at it a bit -- this is my "build
machine," so it doesn't have critical work to do at the moment. (I
would normally have powered it down for the day: here's no need for
it to be wasting energy.)

Laptops are still building ports under stable/14 -- something seems
to want the llvm17 port, and they have firefox to build, so they
won't be testing CURRENT/head for a while, yet.

Peace,
david

--
David H. Wolfskill ***@catwhisker.org
Alexey Navalny was a courageous man; Putin has made him a martyr.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

Rick Macklem

2024-04-09 14:46:28 UTC

Permalink

Post by David Wolfskill
This was an in-place source update, after updating sources to
main-n269230-f6f67f58c19d. On reboot (after "make installworld"
...
Starting lockd.

I'd guess this is caused by some recent change to AF_UNIX socket
creation. The crash appears to be either the SOCK_LOCK() or
SOCKBUF_LOCK(&so->so_rcv) not being initialized.
If you can find out what source line# corresponds to
clnt_vc_create+0x4f4 you can probably tell which one it is.

All local_rpcb() does is a
error = socreate(AF_LOCAL, &so, SOCK_STREAM, 0, curthread->td_ucred,
curthread);
and then calls clnt_vc_create(..so..) with the socket.

I think that socreate() is not initializing one of those two mutexes
for some reason.

rick

Post by David Wolfskill
Fatal trap 12: page fault while in kernel mode
cpuid = 9; apic id = 09
fault virtual address = 0x18
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80b208c5
stack pointer = 0x28:0xfffffe048c204920
frame pointer = 0x28:0xfffffe048c204960
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 1208 (rpc.Starting automountd.
lockd)
rdi: 0000000000000000 rsi: fffff801078b0740 rdx: 0000000000000000
rcx: 000000000000010a r8: ffffffff818d30f0 r9: 0000000000000000
rax: 0000000000000000 rbx: 00000000Starting powerd.00000018 rbp: fffffe048c204960
r10: 0000000000010000 r11: 0000000000000001 r12: fffff80274e32c18
r13: 000000000000010a r14: fffff80274e32c00 r15: ffffffff812ae38a
trap number = 12
panic: page fault
cpuid = 9
time = 1712662362
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe048c2045f0
vpanic() at vpanic+0x135/frame 0xfffffe048c204720
panic() at panic+0x43/frame 0xfffffe048c204780
trap_fatal() at trap_fatal+0x40b/frame 0xfffffe048c2047e0
trap_pfault() at trap_pfault+0xa0/frame 0xfffffe048c204850
calltrap() at calltrap+0x8/frame 0xfffffe048c204850
--- trap 0xc, rip = 0xffffffff80b208c5, rsp = 0xfffffe048c204920, rbp = 0xfffffe
048c204960 ---
__mtx_lock_flags() at __mtx_lock_flags+0x45/frame 0xfffffe048c204960
clnt_vc_create() at clnt_vc_create+0x4f4/frame 0xfffffe048c204ab0
local_rpcb() at local_rpcb+0x11b/frame 0xfffffe048c204b50
rpcb_unset() at rpcb_unset+0x24/frame 0xfffffe048c204bb0
svc_tp_create() at svc_tp_create+0xee/frame 0xfffffe048c204c90
sys_nlm_syscall() at sys_nlm_syscall+0x3d0/frame 0xfffffe048c204e00
amd64_syscall() at amd64_syscall+0x158/frame 0xfffffe048c204f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe048c204f30
--- syscall (154, FreeBSD ELF64, nlm_syscall), rip = 0x3f00a2dfd2a, rsp = 0x3f00
96f7168, rbp = 0x3f0096f7230 ---
KDB: enter: panic
[ thread pid 1208 tid 101107 ]
Stopped at kdb_enter+0x33: movq $0,0x104eb92(%rip)
db>
Given suitable clues, I can poke at it a bit -- this is my "build
machine," so it doesn't have critical work to do at the moment. (I
would normally have powered it down for the day: here's no need for
it to be wasting energy.)
Laptops are still building ports under stable/14 -- something seems
to want the llvm17 port, and they have firefox to build, so they
won't be testing CURRENT/head for a while, yet.
Peace,
david
--
Alexey Navalny was a courageous man; Putin has made him a martyr.
See https://www.catwhisker.org/~david/publickey.gpg for my public key.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Rick Macklem

2024-04-09 15:04:01 UTC

Permalink

Post by Rick Macklem

Post by David Wolfskill
This was an in-place source update, after updating sources to
main-n269230-f6f67f58c19d. On reboot (after "make installworld"
...
Starting lockd.

I'd guess this is caused by some recent change to AF_UNIX socket
creation. The crash appears to be either the SOCK_LOCK() or
SOCKBUF_LOCK(&so->so_rcv) not being initialized.
If you can find out what source line# corresponds to
clnt_vc_create+0x4f4 you can probably tell which one it is.
All local_rpcb() does is a
error = socreate(AF_LOCAL, &so, SOCK_STREAM, 0, curthread->td_ucred,
curthread);
and then calls clnt_vc_create(..so..) with the socket.
I think that socreate() is not initializing one of those two mutexes
for some reason.

Looks to me like this was caused by commit 681711b. I've added tuexen@
to the post, since he committed it.

rick

Post by Rick Macklem
rick

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Rick Macklem

2024-04-09 15:33:06 UTC

Permalink

Post by Rick Macklem

Post by David Wolfskill
This was an in-place source update, after updating sources to
main-n269230-f6f67f58c19d. On reboot (after "make installworld"
...
Starting lockd.

I'd guess this is caused by some recent change to AF_UNIX socket
creation. The crash appears to be either the SOCK_LOCK() or
SOCKBUF_LOCK(&so->so_rcv) not being initialized.
If you can find out what source line# corresponds to
clnt_vc_create+0x4f4 you can probably tell which one it is.
All local_rpcb() does is a
error = socreate(AF_LOCAL, &so, SOCK_STREAM, 0, curthread->td_ucred,
curthread);
and then calls clnt_vc_create(..so..) with the socket.
I think that socreate() is not initializing one of those two mutexes
for some reason.

to the post, since he committed it.

Oops, my bad, got this wrong.

The commit is d80a97d, when it added PR_SOCKBUG to the pr_flags
for AF_UNIX/SOCKSTREAM.
I've added glebius@ to the email.

rick

Post by Rick Macklem
rick

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Gleb Smirnoff

2024-04-09 16:18:49 UTC

Permalink

On Tue, Apr 09, 2024 at 04:47:07AM -0700, David Wolfskill wrote:
D> --- trap 0xc, rip = 0xffffffff80b208c5, rsp = 0xfffffe048c204920, rbp = 0xfffffe
D> 048c204960 ---
D> __mtx_lock_flags() at __mtx_lock_flags+0x45/frame 0xfffffe048c204960
D> clnt_vc_create() at clnt_vc_create+0x4f4/frame 0xfffffe048c204ab0
D> local_rpcb() at local_rpcb+0x11b/frame 0xfffffe048c204b50
D> rpcb_unset() at rpcb_unset+0x24/frame 0xfffffe048c204bb0
D> svc_tp_create() at svc_tp_create+0xee/frame 0xfffffe048c204c90
D> sys_nlm_syscall() at sys_nlm_syscall+0x3d0/frame 0xfffffe048c204e00
D> amd64_syscall() at amd64_syscall+0x158/frame 0xfffffe048c204f30
D> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe048c204f30
D> --- syscall (154, FreeBSD ELF64, nlm_syscall), rip = 0x3f00a2dfd2a, rsp = 0x3f00
D> 96f7168, rbp = 0x3f0096f7230 ---
D> KDB: enter: panic
D> [ thread pid 1208 tid 101107 ]
D> Stopped at kdb_enter+0x33: movq $0,0x104eb92(%rip)
D> db>

This should be fixed by just pushed e205fd318a296ffdb7392486cdcec7f660fcffcf.

Sorry for that!

--
Gleb Smirnoff

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

David Wolfskill

2024-04-09 16:41:15 UTC

Permalink

Post by Gleb Smirnoff
...
D> db>
This should be fixed by just pushed e205fd318a296ffdb7392486cdcec7f660fcffcf.

Thanks! :-)

Post by Gleb Smirnoff
Sorry for that!
....

Glad it's idenitfied & addressed.

[Sorry for delay; commute this morning was a bit more turbulent than
usual.]

Peace,
david

--
David H. Wolfskill ***@catwhisker.org
Alexey Navalny was a courageous man; Putin has made him a martyr.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

David Wolfskill

2024-04-10 11:22:11 UTC

Permalink

After the update to main-n269261-1e6db7be6921, head built & booted OK.

FreeBSD 15.0-CURRENT #45 main-n269261-1e6db7be6921: Wed Apr 10 11:11:50 UTC 2024 ***@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1500018 1500018

Peace,
david

--
David H. Wolfskill ***@catwhisker.org
Alexey Navalny was a courageous man; Putin has made him a martyr.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

FreeBSD User

2024-04-09 17:02:11 UTC

Permalink

Am Tue, 9 Apr 2024 09:18:49 -0700

Post by Gleb Smirnoff
D> --- trap 0xc, rip = 0xffffffff80b208c5, rsp = 0xfffffe048c204920, rbp = 0xfffffe
D> 048c204960 ---
D> __mtx_lock_flags() at __mtx_lock_flags+0x45/frame 0xfffffe048c204960
D> clnt_vc_create() at clnt_vc_create+0x4f4/frame 0xfffffe048c204ab0
D> local_rpcb() at local_rpcb+0x11b/frame 0xfffffe048c204b50
D> rpcb_unset() at rpcb_unset+0x24/frame 0xfffffe048c204bb0
D> svc_tp_create() at svc_tp_create+0xee/frame 0xfffffe048c204c90
D> sys_nlm_syscall() at sys_nlm_syscall+0x3d0/frame 0xfffffe048c204e00
D> amd64_syscall() at amd64_syscall+0x158/frame 0xfffffe048c204f30
D> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe048c204f30
D> --- syscall (154, FreeBSD ELF64, nlm_syscall), rip = 0x3f00a2dfd2a, rsp = 0x3f00
D> 96f7168, rbp = 0x3f0096f7230 ---
D> KDB: enter: panic
D> [ thread pid 1208 tid 101107 ]
D> Stopped at kdb_enter+0x33: movq $0,0x104eb92(%rip)
D> db>
This should be fixed by just pushed e205fd318a296ffdb7392486cdcec7f660fcffcf.
Sorry for that!

Hello all.

The crash is still present on the most recent checked out sources as of minutes ago.

I just checked out on HEAD the latest commits (see below, just for the record and to prevent
being wrong here).

[...]
commit 841cf52595b6a6b98e266b63e54a7cf6fb6ca73e (HEAD -> main, origin/main, origin/HEAD)
Author: Alan Cox <***@FreeBSD.org>
Date: Mon Apr 8 00:05:27 2024 -0500

arm64 pmap: Add ATTR_CONTIGUOUS support [Part 2]

Create ATTR_CONTIGUOUS mappings in pmap_enter_object(). As a result,
when the base page size is 4 KB, the read-only data and text sections
of large (2 MB+) executables, e.g., clang, can be mapped using 64 KB
pages. Similarly, when the base page size is 16 KB, the read-only
data section of large executables can be mapped using 2 MB pages.

Rename pmap_enter_2mpage(). Given that we have grown support for 16 KB
base pages, we should no longer include page sizes that may vary, e.g.,
2mpage, in pmap function names. Requested by: andrew

Co-authored-by: Eliot Solomon <***@rice.edu>
Differential Revision: https://reviews.freebsd.org/D44575

commit e205fd318a296ffdb7392486cdcec7f660fcffcf
Author: Gleb Smirnoff <***@FreeBSD.org>
Date: Tue Apr 9 09:16:52 2024 -0700

rpc: use new macros to lock socket buffers

Fixes: d80a97def9a1db6f07f5d2e68f7ad62b27918947

commit cb20a74ca06381e96c41cb4495d633710cc6cb79
Author: Stephen J. Kiernan <***@FreeBSD.org>
Date: Wed Apr 3 17:04:57 2024 -0400

--
O. Hartmann

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Gleb Smirnoff

2024-04-09 17:08:50 UTC

Permalink

On Tue, Apr 09, 2024 at 07:02:11PM +0200, FreeBSD User wrote:
F> The crash is still present on the most recent checked out sources as of minutes ago.
F> I just checked out on HEAD the latest commits (see below, just for the record and to prevent
F> being wrong here).
F>
F> [...]
F> commit 841cf52595b6a6b98e266b63e54a7cf6fb6ca73e (HEAD -> main, origin/main, origin/HEAD)

Is the crash same or different? Can you please share backtrace?

--
Gleb Smirnoff

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Cy Schubert

2024-04-09 17:59:08 UTC

Permalink

Post by David Wolfskill

Post by Gleb Smirnoff
F> The crash is still present on the most recent checked out sources as of

Post by Gleb Smirnoff
nutes ago.
F> I just checked out on HEAD the latest commits (see below, just for the r

Post by Gleb Smirnoff
ord and to prevent
F> being wrong here).
F>
F> [...]
F> commit 841cf52595b6a6b98e266b63e54a7cf6fb6ca73e (HEAD -> main, origin/ma

Post by Gleb Smirnoff
, origin/HEAD)
Is the crash same or different? Can you please share backtrace?

Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address = 0x28
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80729d8d
stack pointer = 0x28:0xfffffe00b59c0a70
frame pointer = 0x28:0xfffffe00b59c0aa0
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 2697 (rpcbind)
rdi: fffff80004fcd720 rsi: 0000000000000000 rdx: fffffe00b59c0b68
rcx: 0000000000000000 r8: 0000000000000001 r9: 000000003b9ac9e0
rax: 000000003b9aca00 rbx: fffffe00b59c0b68 rbp: fffffe00b59c0aa0
r10: 0000000000000020 r11: 00000000ffffffff r12: 0000000000000000
r13: 0000000000000020 r14: 0000000000000020 r15: fffff80004fcd720
trap number = 12
panic: page fault
cpuid = 3
time = 1712682162
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfffffe00b59c0760
vpanic() at vpanic+0x135/frame 0xfffffe00b59c0890
panic() at panic+0x43/frame 0xfffffe00b59c08f0
trap_fatal() at trap_fatal+0x40b/frame 0xfffffe00b59c0950
trap_pfault() at trap_pfault+0x46/frame 0xfffffe00b59c09a0
calltrap() at calltrap+0x8/frame 0xfffffe00b59c09a0
--- trap 0xc, rip = 0xffffffff80729d8d, rsp = 0xfffffe00b59c0a70, rbp =
0xfffffe00b59c0aa0 ---
uiomove_faultflag() at uiomove_faultflag+0x9d/frame 0xfffffe00b59c0aa0
uipc_soreceive_stream_or_seqpacket() at uipc_soreceive_stream_or_seqpacket+0
x38c/frame 0xfffffe00b59c0b30
soreceive() at soreceive+0x2f/frame 0xfffffe00b59c0b50
clnt_vc_soupcall() at clnt_vc_soupcall+0x139/frame 0xfffffe00b59c0c00
sorwakeup_locked() at sorwakeup_locked+0x98/frame 0xfffffe00b59c0c20
uipc_sosend_stream_or_seqpacket() at uipc_sosend_stream_or_seqpacket+0x58e/f
rame 0xfffffe00b59c0ce0
sousrsend() at sousrsend+0x5f/frame 0xfffffe00b59c0d40
dofilewrite() at dofilewrite+0x7f/frame 0xfffffe00b59c0d90
sys_write() at sys_write+0xb3/frame 0xfffffe00b59c0e00
amd64_syscall() at amd64_syscall+0x115/frame 0xfffffe00b59c0f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00b59c0f30
--- syscall (4, FreeBSD ELF64, write), rip = 0x1d82f79281a, rsp =
0x1d82c63be78, rbp = 0x1d82c63bee0 ---
Uptime: 39s
Dumping 515 out of 7969 MB:..4%..13%..22%..32%..41%..53%..63%..72%..81%..91%
(kgdb) bt
#0 __curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:57
utdown.c:404
#2 0xffffffff806bd7d9 in kern_reboot (howto=260) at
/opt/src/git-src/sys/kern/kern_shutdown.c:524
#3 0xffffffff806bdcf2 in vpanic (fmt=0xffffffff80ae0f0d "%s",
:976
#4 0xffffffff806bdb43 in panic (fmt=<unavailable>) at
/opt/src/git-src/sys/kern/kern_shutdown.c:892
#5 0xffffffff80a597fb in trap_fatal (frame=0xfffffe00b59c09b0, eva=40) at
/opt/src/git-src/sys/amd64/amd64/trap.c:950
#6 0xffffffff80a59846 in trap_pfault (frame=<unavailable>, usermode=false,
signo=<optimized out>, ucode=<optimized out>) at /opt/src/git-src/sys/amd64/
amd64/trap.c:758
#7 <signal handler called>
#8 uiomove_faultflag (cp=0xfffff80004fcd720, n=32,
/opt/src/git-src/sys/kern/subr_uio.c:240
#9 0xffffffff80729ce9 in uiomove (cp=0xfffff80004fcd720, n=0,
3
#10 0xffffffff80774f1c in uipc_soreceive_stream_or_seqpacket
(so=0xfffff800361f4000, psa=<optimized out>, uio=0xfffffe00b59c0b68,
mp0=<optimized out>, controlp=0xfffffe00b59c0bc0, flagsp=0xfffffe00b59c0ba8)
at /opt/src/git-src/sys/kern/uipc_usrreq.c:1420
#11 0xffffffff8076d4ff in soreceive (so=0xfffff80004fcd720,
t.c:2965
#12 0xffffffff80917719 in clnt_vc_soupcall (so=0xfffff800361f4000,
arg=0xfffff80036191c00, waitflag=<optimized out>) at
/opt/src/git-src/sys/rpc/clnt_vc.c:991
#13 0xffffffff80765338 in sowakeup (so=0xfffff800361f4000, which=SO_RCV) at
/opt/src/git-src/sys/kern/uipc_sockbuf.c:493
/opt/src/git-src/sys/kern/uipc_sockbuf.c:526
#15 0xffffffff807758ae in uipc_sosend_stream_or_seqpacket
(so=0xfffff800361e4b40, addr=<optimized out>, uio=0xfffffe00b59c0da8,
m=<optimized out>, c=<optimized out>, flags=<optimized out>,
td=0xfffff8001e73e000) at /opt/src/git-src/sys/kern/uipc_usrreq.c:1154
#16 0xffffffff8076b2cf in sousrsend (so=0xfffff80004fcd720, addr=0x0,
uio=0xfffffe00b59c0b68, control=0x1, flags=0, userproc=0x0) at
/opt/src/git-src/sys/kern/uipc_socket.c:1941
#17 0xffffffff8073106f in fo_write (fp=0xfffff800092800a0,
uio=0xfffffe00b59c0da8, active_cred=0xfffffe00b59c0b68,
td=0xfffff8001e73e000, flags=<optimized out>) at /opt/src/git-src/sys/sys/fi
le.h:352
s_generic.c:562
#19 0xffffffff80730c23 in kern_writev (td=0xfffff8001e73e000, fd=14,
auio=0xfffffe00b59c0da8) at /opt/src/git-src/sys/kern/sys_generic.c:489
#20 sys_write (td=0xfffff8001e73e000, uap=<optimized out>) at
/opt/src/git-src/sys/kern/sys_generic.c:404
#21 0xffffffff80a5a0b5 in syscallenter (td=0xfffff8001e73e000) at
/opt/src/git-src/sys/amd64/amd64/../../kern/subr_syscall.c:189
#22 amd64_syscall (td=0xfffff8001e73e000, traced=0) at
/opt/src/git-src/sys/amd64/amd64/trap.c:1192
#23 <signal handler called>
#24 0x000001d82f79281a in ?? ()
Backtrace stopped: Cannot access memory at address 0x1d82c63be78
(kgdb) frame 8
#8 uiomove_faultflag (cp=0xfffff80004fcd720, n=32,
/opt/src/git-src/sys/kern/subr_uio.c:240
240 cnt = iov->iov_len;
(kgdb) p *iov
Cannot access memory at address 0x20
(kgdb) l
235 while (n > 0 && uio->uio_resid) {
236 KASSERT(uio->uio_iovcnt > 0,
237 ("%s: uio %p iovcnt underflow", __func__, uio));
238
239 iov = uio->uio_iov;
240 cnt = iov->iov_len;
241 if (cnt == 0) {
242 uio->uio_iov++;
243 uio->uio_iovcnt--;
244 continue;
(kgdb) p *uio
$1 = {uio_iov = 0x20, uio_iovcnt = 0, uio_offset = 0, uio_resid =
1000000000, uio_segflg = (unknown: 0x80696078), uio_rw = (UIO_WRITE |
unknown: 0xfffffffe), uio_td = 0xfffff8001e73e000}
(kgdb)

uio_iov contains 0x20 at frame 12. Is it because send buffer is now
bypassed, not initializing uio_iov?
--
Cheers,
Cy Schubert <***@cschubert.com>
FreeBSD UNIX: <***@FreeBSD.org> Web: https://FreeBSD.org
NTP: <***@nwtime.org> Web: https://nwtime.org

e^(i*pi)+1=0

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de