BUG: Pthread deadlock in motion 3.2.1
When running with 3 netcams, there are 7 threads/processus, main and 2
threads per netcam (1+3*2=7, no http control, no webcam).
When hitting Ctrl-C, most of the times motion doesn't stop.
Test case
./motion
Processing thread 0 - config file motion.conf
Processing thread 1 - config file /home/motion/motion-3.2.1/thread1.conf
Processing thread 2 - config file /home/motion/motion-3.2.1/thread2.conf
Processing thread 3 - config file /home/motion/motion-3.2.1/thread3.conf
Thread 1 started
Thread 2 started
Thread 3 started
Corrupt JPEG data: premature end of data segment
[1] File of type 8 saved to: /home/motion/public_html/20050517/20050517185723_rdc_01.avi
[msmpeg4v2 @ 0xbad130]warning, cliping 1 dct coefficents to -127..127
...
<Ctrl-C>
Thread 2 exiting
Thread 1 exiting
Motion is still running.
ls -l /proc/`/sbin/pidof motion`/task
total 0
dr-xr-xr-x 3 motion motion 0 May 17 18:57 10182
dr-xr-xr-x 3 motion motion 0 May 17 18:57 10185
strace -p 10185
Process 10185 attached - interrupt to quit
futex(0x90cc01c, FUTEX_WAIT, 2, NULL <unfinished ...>
Environment
Motion version: |
3.2.1 |
ffmpeg version: |
0.4.9pre1 |
Shared libraries: |
ffmpeg |
Server OS: |
Fedora Core 3, kernel 2.6.11 |
--
ChristopheGRENIER - 26 May 2005
Follow up
The seems to be in netcam_cleanup() function where
pthread_cond_destroy(&netcam->which_cond);
is destroying netcam->which_cond and motion waits forever in netcam_next()
pthread_cond_signal(&netcam->which_cond);
So it you remove the pthread_cond_destroy(&netcam->which_cond); line seems there's no deadlock.
--
AngelCarpintero - 26 May 2005
Fix record
I've attached a patch that solves the problem . I'll close this bug , reopen it if the problem remains.
--
AngelCarpintero - 26 May 2005
Fix is now in my 3.2.2_snap1 sources
--
KennethLavrsen - 03 Jun 2005