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 751573 - rtpjpegpay can't handle MJPG from Logitech c615 camera
rtpjpegpay can't handle MJPG from Logitech c615 camera
Status: RESOLVED DUPLICATE of bug 740040
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.4.5
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-06-27 05:48 UTC by Alastair
Modified: 2015-07-03 15:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Full backtrace of all threads (13.01 KB, text/plain)
2015-06-27 05:48 UTC, Alastair
Details
gdp file (334.67 KB, application/octet-stream)
2015-06-27 10:27 UTC, Alastair
Details
Output of valgrind (with -v option) (22.51 KB, text/plain)
2015-06-30 23:22 UTC, Alastair
Details
valgrind report with debugging symbols (23.12 KB, text/plain)
2015-07-01 13:23 UTC, Alastair
Details

Description Alastair 2015-06-27 05:48:13 UTC
Created attachment 306194 [details]
Full backtrace of all threads

When constructing a pipeline that contains rtpjpegpay and is reading data from a logitech c615 camera, I get a segfault. The pipeline was:

"v4l2src device=/dev/video0 ! 'image/jpeg' ! rtpjpegpay ! fakesink"

This was tested through gst-launch and through the c api on 2 separate systems (raspbian stable and debian unstable) with gstreamer 1.4.4 and 1.4.5 with the same results. Changing the pipeline to:

"v4l2src device/dev/video0 ! 'image/jpeg' ! jpegdec ! jpegenc ! rtpjpegpay ! fakesink"

worked in all test scenarios stated above but adds 2 redundant elements to the stream. I'll try and do some testing on a non-debian box later today.
Meanwhile, attached is a backtrace. I'll see if I can work out how to generate a coredump as well.
Comment 1 Tim-Philipp Müller 2015-06-27 07:36:23 UTC
Could you do this:

 gst-launch-1.0 v4l2src device/dev/video0 num-buffers=25 ! 'image/jpeg' ! gdppay ! filesink location=jpeg.gdp

Check that it reproduces the problem with:

 gst-launch-1.0 filesrc location=jpeg.gdp ! gdpdepay ! rtpjpegpay ! fakesink

and then attach it to this bug report (needs to be <1MB). Thanks!
Comment 2 Alastair 2015-06-27 10:27:43 UTC
Created attachment 306198 [details]
gdp file

Unfortunately I couldn't get rtpjpegpay to segfault off of the gdp file :( I've attached the gdp file anyway, just in case there's anything particularly enlightening in it. Any other suggestions for gathering info?
Comment 3 Nicolas Dufresne (ndufresne) 2015-06-30 01:26:48 UTC
Maybe attach a valgrind report of the issue (if it can be reproduces when running inside valgrind). Please don't attach it if you can't reproduce the crash inside valgrind.
Comment 4 Alastair 2015-06-30 23:22:16 UTC
Created attachment 306453 [details]
Output of valgrind (with -v option)

Ok, here's the output of valgrind when running "valgrind -v -- gst-launch-1.0 v4l2src device=/dev/video0 ! 'image/jpeg' ! rtpjpegpay ! fakesink > gst-valgrind 2>&1".
As a side note, I tried running this several times just to see what changed (and what didn't) and it seemed that the line where it says "Address 0xb278000 is not stack'd, malloc'd or (recently) free'd", the address location never changes. Maybe its nothing, but my understanding is that its normal for addresses to change on each subsequent run of a process.
Comment 5 Tim-Philipp Müller 2015-06-30 23:39:20 UTC
Any chance you could install the -dbg/-debug package for gst-plugins-good (or do whatever is needed to install debugging symbols o your distro)?
Comment 6 Nicolas Dufresne (ndufresne) 2015-07-01 00:22:57 UTC
I believe this is fixed in master and 1.4. Would it be possible to verify ? Related bug is:

https://bugzilla.gnome.org/show_bug.cgi?id=740040
Comment 7 Alastair 2015-07-01 13:23:29 UTC
Created attachment 306499 [details]
valgrind report with debugging symbols

I've reattached the report with debugging symbols (the previous one had gstreamer-dbg and plugins-good-dbg, but I'd forgotten to install plugins-base-dbg).

I've also checked manjaro and I can confirm the problem does exist in that distro as well.

In the meantime I'll have a play with the git master branch and report back on whether the problem has been fixed.
Comment 8 Alastair 2015-07-03 15:04:09 UTC
After having compiled master, I can confirm that this is in fact fixed. I'm marking this bug as a duplicate

*** This bug has been marked as a duplicate of bug 740040 ***