On 2024/11/23 17:06, Kirill A. Korinsky wrote:
> >
> > Where is it frozen?  On which sleep channel is ffplay sleeping?  Can you
> > enter ddb and get a trace of the ffplay process?
> >
> 
> When ffplay is complaining ioctl(VIDIOC_DQBUF): Invalid argument, it creates
> a few threads and everything works. When I press C-c on terminal or use
> pkill -KILL ffplay nothing happens, but ffplay changes its state via ps from
> 
>         ~ $ ps aux | grep fplay
>         catap    20332  0.8  0.3 35204 53348 p2  S+      2:05PM    0:00.51 
> ffplay -f v4l2 -i /dev/video1
>         catap    77165  0.0  0.0   796  1376 p4  S+p     2:05PM    0:00.01 
> grep fplay
>         ~ $
> 
> into
> 
>         $ ps aux | grep ffplay
>         catap    20332  0.0  0.3 29280 47628 p2  RE+/2   2:05PM   0:00.63 
> (ffplay)
>         catap    97615  0.0  0.0   100   360 C0  R+/2    2:07PM   0:00.00 
> grep ffplay
>         $
> 
> and there is no ffplay processes by ps in ddb anymore.

that's odd! The 'wait' column in top(1) would be of interest, that's the
wait aka sleep channel.

> and there is no ffplay processes by ps in ddb anymore. I see only uvideo1
> which has stacktrace:
> 
>         ddb{1}> tr /t 0t393427
>         sleep_finish(0,1) at sleep_finish+0x17f
>         usbd_transfer(fffffdb461bb4c08) at usbd_transfer+0x275
>         uvideo_vs_start_bulk_thread(ffff800001b25000) at 
> uvideo_vs_start_bulk_thread+0x7e
>         end trace frame: 0x0, count: -3
>         ddb{1}>
> 
> and when I deattach the webcam from the machine, it crashes with stacktrace:
> 
>         uvm_fault(0xfffffdb32e87f840, 0x3f, 0, 2) -> e
>         kernel: page fault trap, code=2
>         Stopped at    usbd_close_pipe+0x91:   movq    %rcx,0x40(%rax)
>          TID    PID    UID     PRFLAGS     PFLAGS  CPU  COMMAND
>         420740  59811  1000    0x100002        0    0   xconsole
>         421818  10645     0    0x100000     0x80    3   hotplugd
>         205493  61124     0     0x14000    0x200    1   reaper
>         usbd_close_pipe(ffff800001c99000) at usbd_close_pipe+0x91
>         uvideo_close(ffff8000019bf000) at uvideo_close+0x57
>         videoclose(2c81,3,2000,ffff80004d2c16c8) at videoclose+0x63
>         spec_close(ffff80004bf56488) at spec_close+0x107
>         VOP_CLOSE(fffffdd4518e6e78,3,fffffdd3e18fe480,ffff80004d2c16c8) at 
> VOP_CLOSE+0x59
>         vn_closefile(fffffdd825a0edb58,ffff80004d2c16c8) at vn_closefile+0xaf
>         fdrop(fffffdd825a0edb58,ffff80004d2c16c8) at fdrop+0xa5
>         closef(fffffdd825a0edb58,ffff80004d2c16c8) at closef+0xaf
>         fdfree(ffff80004d2c16c8) at fdfree+0xa6
>         exit1(ffff80004d2c16c8,7b,0,1) at exit1+0x29b
>         sys_exit(ffff80004d2c16c8,ffff80004bf56780,ffff80004bf56f80) at 
> sys_exit+0x1a
>         syscall(ffff80004bf56780) at syscall+0x5e7
>         Xsyscall() at Xsyscall+0x128
>         end of kernel
>         end trace frame: 0x761dc4ff9130, count: 2
>         https://www.openbsd.org/ddb.html describes the minimum info required 
> in bug
>         reports.  Insufficient info makes it difficult to find and fix bugs.
>         ddb(2)>
> 
> Here, I double-checked the traces and it shouldn't contain any typos/errors.
> 
> Also, if I wait a few minutes after C-c or kill ffpplay, I can deattach the
> webcam without crashing, and the ffplay process just disappears.
> 
> --
> wbr, Kirill
> 

Reply via email to