Bug 739516 – Segfault when controlling gdkpixbufoverlay's offset-x property

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 739516 - Segfault when controlling gdkpixbufoverlay's offset-x property


Summary:	Segfault when controlling gdkpixbufoverlay's offset-x property


Status:	RESOLVED DUPLICATE of bug 739281

Product:	GStreamer
Classification:	Platform
Component:	gstreamer (core)
Version:	git master
Hardware:	Other Linux

Importance:	Normal normal
Target Milestone:	git master
Assigned To:	GStreamer Maintainers
QA Contact:	GStreamer Maintainers

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2014-11-01 20:54 UTC by Lazar Claudiu
Modified:	2014-11-02 11:01 UTC

See Also:
GNOME target:	---
GNOME version:	---

Attachments
testcase (3.19 KB, text/x-csrc) 2014-11-01 20:55 UTC, Lazar Claudiu		Details
png resource (4.17 KB, image/png) 2014-11-01 20:56 UTC, Lazar Claudiu		Details
Small fix (1.03 KB, patch) 2014-11-02 10:44 UTC, Luis de Bethencourt	none	Details \| Review

Description Lazar Claudiu 2014-11-01 20:54:20 UTC

Backtrace :

Program received signal SIGSEGV, Segmentation fault.

+ Trace 234292

Thread 140737226503936 (LWP 30030)

#0 matrix_rgb_to_yuv
at video-blend.c line 103
#1 gst_video_blend
at video-blend.c line 341
#2 gst_video_overlay_composition_blend
at video-overlay-composition.c line 491
#3 gst_gdk_pixbuf_overlay_transform_frame_ip
at gstgdkpixbufoverlay.c line 531
#4 gst_video_filter_transform_ip
at gstvideofilter.c line 320
#5 gst_base_transform_handle_buffer
at gstbasetransform.c line 2112
#6 gst_base_transform_chain
at gstbasetransform.c line 2224
#7 gst_pad_chain_data_unchecked
at gstpad.c line 3836
#8 gst_pad_push_data
at gstpad.c line 4069
#9 gst_pad_push
at gstpad.c line 4180
#10 gst_base_src_loop
at gstbasesrc.c line 2834
#11 gst_task_func
at gsttask.c line 317
#12 ??
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 ??
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 start_thread
from /lib/x86_64-linux-gnu/libpthread.so.0
#15 clone
from /lib/x86_64-linux-gnu/libc.so.6
#16 ??

Comment 1 Lazar Claudiu 2014-11-01 20:55:33 UTC

Created attachment 289808 [details]
testcase

Comment 2 Lazar Claudiu 2014-11-01 20:56:10 UTC

Created attachment 289809 [details]
png resource

Comment 3 Luis de Bethencourt 2014-11-01 20:58:22 UTC

Lazar,

Do you know what is the value of tmpline? Is it !NULL?

Comment 4 Lazar Claudiu 2014-11-01 21:00:59 UTC

Luis,

Trace says "tmpline=tmpline@entry=0x83afd0"

Comment 5 Luis de Bethencourt 2014-11-01 21:10:57 UTC

Segfault reproduced with 1.4 stable release.

Comment 6 Luis de Bethencourt 2014-11-01 21:24:32 UTC

Reproduced with git master.

Comment 7 Luis de Bethencourt 2014-11-01 21:33:17 UTC

this breaks in line

gst-libs/gst/video/video-blend.c:106
> r = tmpline[i * 4 + 1];

i (which is a loop from 0 to width ) is out of bounds because for same strange reason width is -21474516.

Comment 8 Lazar Claudiu 2014-11-01 21:54:07 UTC

Must be something the controller does, if line 55 is commented the segfault doesn't happen.

Comment 9 Luis de Bethencourt 2014-11-01 22:00:06 UTC

Yes, the controller sets the offset-x to 2147483266. Which is waaay out of the image.

Then in gst_video_blend () this happens and makes the src_width a big negative number.

>     src_width = dest_width - x;

Comment 10 Luis de Bethencourt 2014-11-02 10:44:38 UTC

Created attachment 289827 [details] [review]
Small fix

This is a hacky fix until I understand a bit better what the code intends to do here, and how wacky x offsets should actually be handled. This patch will just not blend the images if this is the case.

Comment 11 Vineeth 2014-11-02 10:47:48 UTC

https://bugzilla.gnome.org/show_bug.cgi?id=739281

This bug is probably duplicate of the above mentioned bug..
applying the changes from 739281 will fix this i guess 
can you please verify..

Comment 12 Lazar Claudiu 2014-11-02 10:50:19 UTC

I wrongly understood how the controller works, that value stems from the fact that the controller maps the values to the property range so 1.0 means 2147483647 for offset-x.

Should've controlled relative-x instead

Comment 13 Luis de Bethencourt 2014-11-02 11:01:41 UTC


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