After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 375476 - v4l2src cannot close /dev/video0
v4l2src cannot close /dev/video0
Status: VERIFIED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other All
: Normal normal
: 0.10.5
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-11-15 11:17 UTC by Fredrik Persson
Modified: 2006-11-18 18:15 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Debug log (418.14 KB, application/x-gzip)
2006-11-15 12:34 UTC, Fredrik Persson
Details

Description Fredrik Persson 2006-11-15 11:17:41 UTC
Please describe the problem:
When a v4l2src element is set to NULL state, it should close the video device (typically /dev/video0). It does not.

Steps to reproduce:
0. Make sure there's some kind of v4l2 device attached to the PC so that /dev/video0 exists
1. Start a python interpreter
2. 'myv4l2srcelement = gst.element_factory_make('v4l2src')
3. 'myv4l2srcelement.set_state(gst.STATE_PAUSED)'
4. 'myv4l2srcelement.set_state(gst.STATE_NULL)' 

Actual results:
This error message is shown:

GStreamer-CRITICAL **: Failed to deactivate pad v4l2src0:src, very bad

... and furthermore, /dev/video0 is not closed. (Creating another v4l2src element and trying to set *that* element into PAUSED state will fail because of this.)

Expected results:
No error message and a closed /dev/video0

Does this happen every time?
Yes

Other information:
I have sent an email to gstreamer-devel about this what contains a program which displays the bug, but that program is larger than it needs be and the above procedure shows the presence of the bug just as well.
Comment 1 Tim-Philipp Müller 2006-11-15 12:18:47 UTC
Could you create a full debug log?

  $ export GST_DEBUG_NO_COLOR=1
  $ GST_DEBUG=*:5 python test.py 2>dbg.log
  $ gzip dbg.log

and then attach dbg.log.gz?


Probably unrelated, but I wonder if there are brackets missing in gst_v4l2src_capture_deinit(), line 640-644 - it seems to me that try_reinit should only be set to TRUE if the ioctl failed.
Comment 2 Fredrik Persson 2006-11-15 12:34:02 UTC
Created attachment 76632 [details]
Debug log

Here you go. The ugly stuff seems to happen around line 43620. (Or search for the string "deinitting".)
Comment 3 Fredrik Persson 2006-11-15 12:36:14 UTC
I agree with #1 about the missing brackets - both that they seem to be missing and that it probably doesn't fix this bug to add them, becuase the ioctl *does* fail here.
Comment 4 Edgard Lima 2006-11-17 14:55:33 UTC
Hi frepe,

I just comit to cvs....could you please update you source/compile and test it again.

BR,
Edgard
Comment 5 Fredrik Persson 2006-11-18 11:30:41 UTC
I can confirm that CVS rev. 1.48 of v4l2src_calls.c fixes this problem. Setting to FIXED.
Comment 6 Fredrik Persson 2006-11-18 11:37:41 UTC
Since I am the reporter I can also VERIFY that this bug is now gone.
Comment 7 Tim-Philipp Müller 2006-11-18 18:15:45 UTC
Also fixed the brackets:

  2006-11-18  Tim-Philipp Müller  <tim at centricular dot net>

        * sys/v4l2/v4l2src_calls.c: (gst_v4l2src_capture_deinit):
          Add missing curly brackets.