Page MenuHomePhabricator

Crash in function evas_object_clip_changes_clean while aging test.
Closed, WontfixPublic



We are getting crash in function evas_object_clip_changes_clean while aging test.

(gdb) frame 1
#1 evas_object_clip_changes_clean (eo_obj=eo_obj@entry=0x80011089) at lib/evas/canvas/evas_object_main.c:442
442 lib/evas/canvas/evas_object_main.c: No such file or directory.
(gdb) p *obj
$1 = {__in_list = {next = 0x0, prev = 0x5fe0b8, last = 0x0}, type = 0x443d83c8 <o_type> "textblock", layer = 0x831b0, cur = 0x475c20, prev = 0x475c20, name = 0x0,

interceptors = 0x0, grabs = 0x0, callbacks = 0x469ba0, clip = {clipees = 0x0, cache_clipees_answer = 0x0, changes = 0x1, mask = 0x0, prev_mask = 0x0},

(gdb) p obj->clip.changes
$8 = (Eina_List *) 0x1

value of obj->clip.changes gets== 0x1

Reproducible steps are not know and its behavior is very random.

(gdb) bt
#0 eina_list_data_get (list=<optimized out>) at ../src/lib/eina/eina_inline_list.x:47
#1 evas_object_clip_changes_clean (eo_obj=eo_obj@entry=0x80011089) at lib/evas/canvas/evas_object_main.c:442
#2 0x44311682 in evas_object_textblock_render_post (eo_obj=0x80011089, obj=<optimized out>, type_private_data=<optimized out>)

at lib/evas/canvas/evas_object_textblock.c:12651

#3 0x44332552 in evas_render_updates_internal (eo_e=eo_e@entry=0x80000604, make_updates=make_updates@entry=1 '\001', do_draw=do_draw@entry=1 '\001',

done_func=done_func@entry=0x0, done_data=done_data@entry=0x0, do_async=do_async@entry=0 '\000') at lib/evas/canvas/evas_render.c:2601

#4 0x44332e18 in evas_render_updates_internal_wait (eo_e=0x80000604, make_updates=<optimized out>, do_draw=<optimized out>) at lib/evas/canvas/evas_render.c:2874
#5 0x442d3170 in evas_canvas_render_updates () at ../src/lib/evas/canvas/evas_canvas.eo.c:336
#6 0x442d6a8e in evas_render_updates (obj=<optimized out>) at ../src/lib/evas/canvas/evas_canvas.eo.c:1064
#7 0xb61034c6 in _ecore_evas_x_render (ee=0x8ffc0) at modules/ecore_evas/engines/x/ecore_evas_x.c:941
#8 0x446dc33c in _ecore_evas_idle_enter (data=<optimized out>) at lib/ecore_evas/ecore_evas.c:168
#9 0x435aec96 in _ecore_call_task_cb (data=<optimized out>, func=<optimized out>) at lib/ecore/ecore_private.h:331
#10 _ecore_idle_enterer_call () at lib/ecore/ecore_idle_enterer.c:180
#11 0x435b1ba8 in _ecore_main_loop_iterate_internal (once_only=once_only@entry=0) at lib/ecore/ecore_main.c:1877
#12 0x435b2724 in ecore_main_loop_begin () at lib/ecore/ecore_main.c:988
#13 0x45502e92 in appcore_efl_main () from ./symbols/usr/lib/
#14 0x45562790 in ui_app_main (argc=10, argv=0x255d58, callback=<optimized out>, user_data=<optimized out>)

at /usr/src/debug/capi-appfw-application-

#15 0xb4e119d0 in ?? ()
#16 0xb4e119d0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?) created this task.Feb 9 2016, 12:03 AM updated the task description. (Show Details) raised the priority of this task from to Incoming Queue. assigned this task to jpeg. added a subscriber: triaged this task as High priority.Feb 9 2016, 12:28 AM
jpeg added a subscriber: tasn.Feb 15 2016, 8:28 PM

It looks like the object is deleted. Without more information, it will be hard to solve this issue. Also, the line numbers don't match EFL upstream codebase, so we don't know if render_post was called from the active_objects list or the render_objects list.
This looks like it's running in GL (do_async = 0).

I have a vague idea (data_ref doesn't actually keep the object alive), but I need to first check with @tasn about the internals of EO.

tasn added a subscriber: cedric.Feb 18 2016, 7:48 AM

Just to update this. As @jpeg checked and found out, data ref doesn't actually ref the object. @cedric wrote it, and didn't do it. I guess it's just there for debug (that's awfully confusing)?

Anyhow, we should at the very least add an error on destruction, I'll do it now, so we have something for now.

tasn added a comment.Feb 18 2016, 7:56 AM

Btw, just to clarify something that is kinda related to my original objection to data_ref: using and storing the data directly is a bad idea. We use it internally for optimisations, but it's generally not recommended otherwise, so if your code is using it. Stop.

Anyhow, the error message is now in.

raster closed this task as Wontfix.Jul 14 2016, 12:06 AM
raster added a subscriber: raster.

well we didnt get more details on this and this is with an older codebase we cant match up... not like we can do much about this until we get more data/info/reports on newer code. wontfix because "can't fix" not enough info and no more info coming atm.