GNOME Bugzilla – Bug 752014
bayer2rgb: odd width causes segmentation fault
Last modified: 2018-11-03 13:37:05 UTC
I am trying to develop a component that uses the x-bayer format. After trying to debug a segmentation fault I reached this pipeline: gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-bayer ! bayer2rgb ! ximagesink The pipeline Starts normally, then the ximagesink causes a renegotiation to happen to maximize the framesize. That causes a segmentation fault. I cannot determine if the problem is the bayer2rgb component or the v4l2src.
Thanks for taking the time to report this. Without a stack trace from the crash it's very hard to determine what caused it. Can you get us a stack trace? Please see https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces for more information on how to do so. When pasting a stack trace in this bug report, please reset the status of this bug report from NEEDINFO to its previous status. Thanks in advance! a GST_DEBUG=6 showing the issue might also be helpful in debugging.
Created attachment 306930 [details] Backtrace
Created attachment 306931 [details] Last ~100 lines of debug messages before segmentation fault
I have added the Backtrace for the segmentation fault and the last 100 lines of debug messages before the segmenetation. The debug was too large and exceeded the file limits of bugzilla, if needed I can post the entire dump on a file sharing site. I have installed the debug sumbols for orc, however, gdb does not seem to resolve the symbols for the orc call inside the tmp-orc.c file that is generated. I generated the file, however there are only orc calls in it.
Created attachment 307399 [details] [review] fix crash using non existent caps structure I don't think this fixes that issue (unless you have asserts off), but I got another crash trying to repro this issue. It works "fine" with your original command line (pipeline errors out) but crashes in transform_caps if I use xvimagesink instead of ximagesink. I'm not pushing it right away because I'm not quite sure whether the new test is sufficient. I don't think we could get ANY here, due to the template caps, but I'm not 100% confident.
I tested the patch out of curiosity and it doesn't fix the segmentation fault I have been dealing with.
To reproduce, without v4l2: gst-launch-1.0 videotestsrc ! rgb2bayer ! bayer2rgb ! ximagesink Resize the window, it crashes.
It crashes if width is odd.
I didn't two unrelated fixes, but one need to figure-out how to fix odd width support. commit 6bd93bd7e5b68294bcb305cd01355477f804b316 Author: Nicolas Dufresne <nicolas.dufresne@collabora.com> Date: Thu Aug 6 18:04:58 2015 -0400 bayer2rgb: Read stride from the video info commit 7d6fd42726a9e1f2705ee21bbc756cdd16460750 Author: Nicolas Dufresne <nicolas.dufresne@collabora.com> Date: Thu Aug 6 18:04:41 2015 -0400 bayer2rgb: Protect against failing map
Two observations: 1) Doesn't happen with ORC_CODE=backup 2) Happens when passing a less than 8-aligned dest pointer to the orc merge functions. The unit size calculation seems to use width * height * 4, so strides and rows will always be 8-aligned if width is even.
Simpler way to reproduce: gst-launch-1.0 -f videotestsrc num-buffers=1 ! video/x-raw,width=319,height=240 ! rgb2bayer ! bayer2rgb ! fakesink (There also seem to be some stride/size inconsistencies between the elements on the bayer side of things.)
Created attachment 318549 [details] [review] bayer: fix stride inconsistencies for odd widths (Doesn't fix this bug, just cleans up an inconsistency in the codebase. The bug here appears to be about strides/offsets on the RGB video buffer side of things, not the Bayer buffer.) Consistently use GST_ROUND_UP_4(width) as stride for bayer buffers. Bayer data will usually come in widths that are multiples of 4 anyway, so hopefully this should not have any adverse impact on anyone in practice. Before, bayer2rgb required input buffers to are sized accordingly, but then didn't actually round up when calculating row offsets. rgb2bayer didn't use a rounded stride nor buffer size.
Hi, It's not exactly the same bug but in the same file, somehow when running something like this: gst-launch-1.0 --no-fault filesrc location=/home/cJ/pouet.raw ! video/x-bayer,format=rggb,width=4096,height=2048,framerate=30/1 ! bayer2rgb ! video/x-raw,format=RGBx ! fakesink I get: WARNING **: bayer2rgb0: size 4096 is not a multiple of unit size 8388608 This is with bayer2rgb v1.8.2.
Do you have a test file replacing filesrc with videotestsrc works, so it's liekly particular to the file.
> It's not exactly the same bug but in the same file, somehow when running > something like this: > > gst-launch-1.0 --no-fault filesrc location=/home/cJ/pouet.raw ! > video/x-bayer,format=rggb,width=4096,height=2048,framerate=30/1 ! bayer2rgb > ! video/x-raw,format=RGBx ! fakesink > > I get: > > WARNING **: bayer2rgb0: size 4096 is not a multiple of unit size 8388608 > > This is with bayer2rgb v1.8.2. This is not related and not expected to work. You need to teach videoparse bayer formats and then use that.
Comment on attachment 307399 [details] [review] fix crash using non existent caps structure This should be fixed at the basetransform level. Most calls already prevent this, at least one doesn't.
Attachment 318549 [details] pushed as d42177c - bayer: fix stride inconsistencies for odd widths
More left to do here
Reducing priority since the crash has been fixed(?).
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/268.