NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
kern/60332: system crashed when ^C on midiplay hung and i turned the synth off
>Number: 60332
>Category: kern
>Synopsis: system crashed when ^C on midiplay hung and i turned the synth off
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Jun 14 23:50:00 +0000 2026
>Originator: matthew green
>Release: 11 RC1.
>Organization:
people's front against (bozotic) www (softwar foundation)
>Environment:
Thinkpad A475, amd64
NetBSD 11.0_RC1 (_wreakage_) #4: Mon Mar 16 00:36:38 PDT 2026
>Description:
i was running "midiplay" against a synth when i realised i'd sent it
the wrong file, so i hit ^C and was waiting for it to complete (this
can take a long time depending on how much midi data is buffered),
but something was wrong with the host at this point, as it never finished
(the midi track wasn't nearly this long). eventually i turned the synth
off as a hope it would kill the midiplay and i could turn it back on and
keep working, but unfortunately it crashed at this point (i have a core
file). before i turned the synth off, i did inspect midiplay process as
best as i could. this is what i found before crash:
ps output:
mrg 1256 0.0 0.1 23936 8684 pts/1 DE+ 11:32PM 0:00.04 (midiplay)
crash outout:
1256 1256 3 0 0 ffff891e4127f400 midiplay midiwr
crash> bt/a ffff891e4127f400
trace: pid 1256 lid 1256 at 0xffffa384b727ba80
sleepq_block() at sleepq_block+0xee
cv_wait() at cv_wait+0xca
midiclose() at midiclose+0x4e
cdev_close() at cdev_close+0x91
spec_close() at spec_close+0x22e
VOP_CLOSE() at VOP_CLOSE+0x40
vn_close() at vn_close+0x34
sequencerclose() at sequencerclose+0xe7
cdev_close() at cdev_close+0x91
spec_close() at spec_close+0x22e
VOP_CLOSE() at VOP_CLOSE+0x40
vn_close() at vn_close+0x34
closef() at closef+0x9a
fd_free() at fd_free+0xfa
exit1() at exit1+0x119
sys_exit() at sys_exit+0x3b
syscall() at syscall+0x9d
--- syscall (number 1) ---
syscall+0x9d:
crash>
the dmesg after rebooting shows what happened:
vnode 0xffff89201a78ccc0 flags 0x8010<MPSAFE,DEADCHECK>
tag VT_NON(0) type VCHR(4) mount 0xffff8920c27b0000 typedata 0xffff8920403742c0
usecount 3 writecount 0 holdcount 0
size 0 writesize 0 numoutput 0
data 0x0 lock 0xffff89201a78ce80
state RECLAIMING key(0xffff8920c27b0000 0)
lrulisthd 0xffffffff8148f9d0
panic: state is RECLAIMING, usecount 3, expected ACTIVE at genfs_lock:400
cpu1: Begin traceback...
vpanic() at netbsd:vpanic+0x171
vnpanic() at netbsd:vnpanic+0x49
_vstate_assert() at netbsd:_vstate_assert+0x19f
genfs_lock() at netbsd:genfs_lock+0x46
VOP_LOCK() at netbsd:VOP_LOCK+0xcc
vn_lock() at netbsd:vn_lock+0xb0
spec_close() at netbsd:spec_close+0x291
VOP_CLOSE() at netbsd:VOP_CLOSE+0x40
vn_close() at netbsd:vn_close+0x34
sequencerclose() at netbsd:sequencerclose+0xe7
cdev_close() at netbsd:cdev_close+0x91
spec_close() at netbsd:spec_close+0x22e
VOP_CLOSE() at netbsd:VOP_CLOSE+0x40
vn_close() at netbsd:vn_close+0x34
closef() at netbsd:closef+0x9a
fd_free() at netbsd:fd_free+0xfa
exit1() at netbsd:exit1+0x119
sys_exit() at netbsd:sys_exit+0x3b
syscall() at netbsd:syscall+0x9d
--- syscall (number 1) ---
i have a core file, but i did not keep matching sources for this, not
even a netbsd.gdb, so i'd have to recreate from a partial guess of
changes. (it would likely be not very long before the kernel was
built, so march 15 or so.)
midi device involved with crash:
umidi0 at uhub5 port 2 configuration 1 interface 0
umidi0: KORG INC. (0x0944) microKORG XL (0x010b), rev 1.10/1.00, addr 3
umidi0: (genuine USB-MIDI)
umidi0: out=2, in=2
midi1 at umidi0: <0 >0 on umidi0
midi2 at umidi0: <1 >1 on umidi0
>How-To-Repeat:
not sure. i've used ^C a lot of times and it never did this before.
>Fix:
Home |
Main Index |
Thread Index |
Old Index