Page MenuHomePhabricator

Evas segfaults on recent builds of x86
Closed, ResolvedPublic


In my recent builds of EFL, there's a segfault related to Evas

I have not see yet this issue on 64bit builded packages, it happens in the 32bit ones (x86)

There's a gdb log, running terminology, which segfaults after 2 left clicks (open menu, close menu, segfaulted):

gdb$ run
Starting program: /usr/bin/terminology
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/".
[New Thread 0xb4ebbb40 (LWP 19021)]
[Detaching after fork from child process 19022]
[New Thread 0xb44ffb40 (LWP 19023)]
[Thread 0xb44ffb40 (LWP 19023) exited]
[New Thread 0xb2b76b40 (LWP 19028)]
[Thread 0xb2b76b40 (LWP 19028) exited]
[Detaching after fork from child process 19029]
[New Thread 0xb2b76b40 (LWP 19057)]

Thread 2 "Eevas-thread-wk" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb4ebbb40 (LWP 19021)]
  EAX: 0xB7E62ED0  EBX: 0xB1F851A0  ECX: 0x001A001A  EDX: 0xD51A1A1A  o d I t S z a p c
  ESI: 0xB4EF0008  EDI: 0x7FFF2A22  EBP: 0x000000B9  ESP: 0xB4EBA870  EIP: 0xB7D654F7
  CS: 0073  DS: 007B  ES: 007B  FS: 0000  GS: 0033  SS: 007B
=> 0xb7d654f7 <_op_blend_p_caa_dp_sse3+791>:    lddqu  xmm1,[esi-0x10]
   0xb7d654fc <_op_blend_p_caa_dp_sse3+796>:    sub    edi,0x8
   0xb7d654ff <_op_blend_p_caa_dp_sse3+799>:    movdqa xmm0,XMMWORD PTR [eax+0x1fdc0]
   0xb7d65507 <_op_blend_p_caa_dp_sse3+807>:    movdqa xmm7,xmm3
   0xb7d6550b <_op_blend_p_caa_dp_sse3+811>:    movdqa xmm2,XMMWORD PTR [eax+0x1fdb0]
   0xb7d65513 <_op_blend_p_caa_dp_sse3+819>:    psrld  xmm7,0x8
   0xb7d65518 <_op_blend_p_caa_dp_sse3+824>:    pand   xmm3,xmm0
   0xb7d6551c <_op_blend_p_caa_dp_sse3+828>:    pand   xmm7,xmm0
_op_blend_p_caa_dp_sse3 (s=<optimized out>, m=0x0, c=0xb9, d=<optimized out>, l=0x7fff2a22) at ../src/lib/evas/common/evas_op_blend/op_blend_pixel_color_sse3.c:218
218     ../src/lib/evas/common/evas_op_blend/op_blend_pixel_color_sse3.c: No existe el fichero o el directorio.
gdb$ bt
#0  _op_blend_p_caa_dp_sse3 (s=<optimized out>, m=0x0, c=0xb9, d=<optimized out>, l=0x7fff2a22)
    at ../src/lib/evas/common/evas_op_blend/op_blend_pixel_color_sse3.c:218
#1  0xb7bf1129 in _map_triangle_draw_linear (src=src@entry=0x8853d0, dst=dst@entry=0x9ca960, cx=cx@entry=0xbc, cy=0x1, cw=0x12, ch=0xe,
    mask=0x0, mx=0x0, my=0x0, ystart=0x1, yend=0xa, tbuf=0xb4ebab60, func=0xb7d651e0 <_op_blend_p_caa_dp_sse3>, func2=0x0,
    mul_col=0xb8b8b8b8, col_blend=0x0, aa_spans=0x0) at ../src/lib/evas/common/evas_map_image_internal_high.c:481
#2  0xb7bf17c3 in _map_triangle_draw (src=src@entry=0x8853d0, dst=dst@entry=0x9ca960, cx=cx@entry=0xbc, cy=0x1, cw=0x12, ch=0xe,
    mask=0x0, mx=0x0, my=0x0, tbuf=0xb4ebab60, func=0xb7d651e0 <_op_blend_p_caa_dp_sse3>, func2=0x0, poly=0xb4ebac7c, mul_col=0xb8b8b8b8,
    col_blend=0x0, smooth=0x1, aa_spans=0x0) at ../src/lib/evas/common/evas_map_image_internal_high.c:660
#3  0xb7bf2770 in _evas_common_map_rgba_internal_high (src=src@entry=0x8853d0, dst=dst@entry=0x9ca960, cx=cx@entry=0xbc, cy=0x1, cw=0x12,
    ch=0xe, mul_col=0xb8b8b8b8, render_op=0x0, p=0xa08ea0, smooth=0x1, mask=0x0, mask_x=0x0, mask_y=0x0, level=0x0, anti_alias=0x1)
    at ../src/lib/evas/common/evas_map_image_internal_high.c:888
#4  0xb7bfb6c5 in evas_common_map_rgba_draw (src=0x8853d0, dst=0x9ca960, clip_x=0xbc, clip_y=0x1, clip_w=0x12, clip_h=0xe,
    mul_col=0xb8b8b8b8, render_op=0x0, npoints=0x4, p=0xa08ea0, smooth=0x1, anti_alias=0x1, level=0x0, mask_ie=0x0, mask_x=0x0,
    mask_y=0x0) at ../src/lib/evas/common/evas_map_image.c:898
#5  0xb7b8ffb5 in _draw_thread_map_draw (data=0xa167a8) at ../src/modules/evas/engines/software_generic/evas_engine.c:2593
#6  0xb7beadd5 in evas_thread_worker_func (data=0x0, thread=<optimized out>) at ../src/lib/evas/common/evas_thread_render.c:170
#7  0xb7a493ef in _eina_internal_call (context=0x4e2da0) at ../src/lib/eina/eina_thread.c:151
#8  0xb71c3fd2 in start_thread (arg=<optimized out>) at pthread_create.c:486
#9  0xb70d96d6 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108

Some days ago, also happened with a different build but even worse (terminology opens and directly segfaults before to do anything)

raster reassigned this task from raster to Hermet.Aug 8 2019, 12:19 AM
raster added subscribers: Hermet, raster.

hey @Hermet -> i spotted junk rendering with mapped content he other day when playing with the default e theme and the old old old e randr config dialog (you have to check out e18 from git tag and build/run that e.g. in xephyr). when u rotate the screeen you get flashes of junk. i've seen at time other flickers of junk. something broke when you change the sw rendering of mapped content here. i already put in some guards for segv's i saw but .. there must be more issues.

so things i do know:

  • the above bt is in the mapped rendering path
  • i've seen issues with rotated (mapped) content
  • if you git checkout v0.18.0 of enlightenment - compile that + install into maybe /opt/e18, run it in xephyr and open up the screen setup config and rotate that screen with the top-right corner handle you get junk rendered which is obviously pointing to an issue and is easy enough to reproduce


raster edited projects, added efl; removed efl (efl-1.23).
raster triaged this task as High priority.Sep 4 2019, 12:42 AM
raster edited projects, added efl (efl-1.23); removed efl.
stefan_schmidt raised the priority of this task from High to Showstopper Issues.Sep 13 2019, 6:16 AM
stefan_schmidt added a subscriber: stefan_schmidt.

@Thanatermesis can you reproduce this on every terminology start on 32 bit?

I am bumping this to showstopper for now.

@Hermet please find some time to look into this. If we have would have evas segfaulting for every terminology start this would definitely block the release (even if it is "only" 32 bit X86).

no- this happens on 64bit too. the new map rendering code reads out-of-bounds. it miscalculates coordinates and pointer addresses. i've seen it fall over pretty badly when i tested the old screen setup dialog in e where you could rotate the monitor in the gui... :) lots of cases of large amounts of garbage pixels.

just fyi. one solution is to just back out the "new software map rendering code" and go back to the old one for now. it's a "nuclear option" but it'd fix it. i'd rather not though and have @Hermet look at it.

Hermet added a comment.EditedSep 18 2019, 12:36 AM

@raster oh, didn't noticed this ticket. firstly that logic must be only working when the object enables anti_alias + smooth.. did you intend this? because normally we don't enable anti_alias option for evas objects individually,

Firstly, let me try to reproduce this issue and fix it hopefully.

zmike added a subscriber: zmike.Sep 25 2019, 7:32 AM

Any progress on this?

@Hermet just commited this to disable high quality textture mapping for 1.23 and get problems sorted out after the release.

@Thanatermesis could you verify this fixes your problem?

Sorry to not have answered before, I was not receiving notifications until now :)

After playing a while with this, everything seems to work correctly on the build of EFL 1.23

I assume this bug should not be closed yet since its only fixed for the release 1.23?

Correct, the feature was enabled again in master now and we need to make sure it gets fixed before the next release.

Hermet closed this task as Resolved.Jan 3 2020, 3:54 AM

commit dea448d40c2ab2480955a0b3776512355d68a70c (HEAD -> master, origin/master, origin/HEAD)
Author: Hermet Park <>
Date: Fri Jan 3 20:51:21 2020 +0900

evas map: ++Safety for range overflow.

This might fix this issue.