Page MenuHomePhabricator

Segfault when opening 2 glviews
Closed, ResolvedPublic

Description

Reproducible with efl 1.19 beta 2 and git.
Tested with intel drivers.

Open elementary_test and open "GLView Gears" and "GlView Many Gears".
This results in a segfault.

indefini created this task.Mar 8 2017, 4:33 PM
stefan_schmidt added a subscriber: stefan_schmidt.

I can reproduce this. The full backtrace I get looks like below:

#0  0x00007fffe04dc43c in run_vp () from /lib64/libOSMesa.so.8
No symbol table info available.
#1  0x00007fffe04d5142 in _tnl_run_pipeline () from /lib64/libOSMesa.so.8
No symbol table info available.
#2  0x00007fffe04d474c in _tnl_draw_prims () from /lib64/libOSMesa.so.8
No symbol table info available.
#3  0x00007fffe04b9fda in vbo_draw_arrays () from /lib64/libOSMesa.so.8
No symbol table info available.
#4  0x00005555555ba9c3 in draw_gear (gld=gld@entry=0x555555af8620, gear=0x555555f4d0e0, 
    m=m@entry=0x7fffffffdb40, x=x@entry=-3, y=y@entry=-2, angle=394, 
    color=color@entry=0x555555605840 <red>) at bin/elementary/test_glview.c:255
        gl = 0x555556879620
        tmp = {0.0717967525, 0.0539186522, 0.0198264923, 0, -0.0484275334, 0.0552252792, -0.0546282306, 
          0, -0.0500000007, 0.0239352006, 0.0813797712, 0, -0.259807616, -0.193326503, -0.0725498721, 1}
#5  0x00005555555bab58 in gears_draw (gld=0x555555af8620) at bin/elementary/test_glview.c:276
        m = {0.0866025388, 0.0138189951, 0.0469846316, 0, 0, 0.0759347603, -0.0342020132, 0, 
          -0.0500000007, 0.0239352006, 0.0813797712, 0, 0, 0, 0, 1}
        gl = <optimized out>
#6  render_gears (gld=0x555555af8620) at bin/elementary/test_glview.c:283
No locals.
#7  _draw_gl (obj=<optimized out>) at bin/elementary/test_glview.c:484
        gl = 0x555556879620
        gld = 0x555555af8620
#8  0x00007ffff611bf88 in _render_cb (obj=0x4000003fb494efe5, event=<optimized out>)
    at lib/elementary/elm_glview.c:148
        sd = 0x555556874d80
        wd = 0x555556874c40
        __FUNCTION__ = "_render_cb"
#9  0x00007ffff6788716 in _event_callback_call (legacy_compare=0 '\000', event_info=<optimized out>, 
    desc=0x7ffff703ef50 <_EFL_LOOP_EVENT_IDLE_ENTER>, pd=0x5555558a3e10, obj_id=<optimized out>)
    at lib/eo/eo_base_class.c:1445
        ev = {object = 0x400000000494def3, desc = 0x7ffff703ef50 <_EFL_LOOP_EVENT_IDLE_ENTER>, 
          info = 0x0}
        ret = 1 '\001'
        frame = {next = 0x0, idx = 7, inserted_before = 0, generation = 1}
        cb = 0x5555558a3ea0
        lookup = 0x7fffffffdc10
        saved = {__in_list = {next = 0x0, prev = 0x0, last = 0x7fffffffdc10}, 
          desc = 0x7ffff703ef50 <_EFL_LOOP_EVENT_IDLE_ENTER>, current = 6}
        idx = 7
        callback_already_stopped = 0 '\000'
#10 _efl_object_event_callback_call (obj_id=<optimized out>, pd=0x5555558a3e10, 
    desc=0x7ffff703ef50 <_EFL_LOOP_EVENT_IDLE_ENTER>, event_info=<optimized out>)
    at lib/eo/eo_base_class.c:1506
No locals.
#11 0x00007ffff67852bb in efl_event_callback_call (obj=0x400000000494def3, 
    desc=0x7ffff703ef50 <_EFL_LOOP_EVENT_IDLE_ENTER>, event_info=event_info@entry=0x0)
    at lib/eo/efl_object.eo.c:142
        _r = <optimized out>
        ___cache = {index = {{klass = 0x5555558a31e0}}, entry = {{func = 0x5555558a3330}}, off = {{
              off = 80}}, op = 32, generation = 1}
        ___call = {eo_id = 0x400000000494def3, obj = 0x5555558a3dc0, 
          func = 0x7ffff67884b0 <_efl_object_event_callback_call>, data = 0x5555558a3e10, extn1 = 0x0,
         extn2 = 0x4135f170b3333333, extn3 = 0x1, extn4 = 0x0}
        _func_ = <optimized out>
#12 0x00007ffff6e0fafe in _ecore_idle_enterer_call (loop=<optimized out>)
    at lib/ecore/ecore_idle_enterer.c:48
No locals.
#13 0x00007ffff6e128d4 in _ecore_main_loop_iterate_internal (once_only=once_only@entry=0)
    at lib/ecore/ecore_main.c:2293
        next_time = -1
        f = <optimized out>
        p = <optimized out>
#14 0x00007ffff6e12f17 in ecore_main_loop_begin () at lib/ecore/ecore_main.c:1289
No locals.
#15 0x00007ffff6e12f59 in _efl_loop_begin (obj=<optimized out>, pd=<optimized out>)
    at lib/ecore/ecore_main.c:2831
No locals.
#16 0x00007ffff6e107fd in efl_loop_begin (obj=0x400000000494def3) at lib/ecore/efl_loop.eo.c:32
        _r = <optimized out>
        ___cache = {index = {{klass = 0x5555558a31e0}}, entry = {{func = 0x5555558a3700}}, off = {{
              off = 144}}, op = 64, generation = 1}
        ___call = {eo_id = 0x400000000494def3, obj = 0x5555558a3dc0, 
          func = 0x7ffff6e12f50 <_efl_loop_begin>, data = 0x5555558a3e50, extn1 = 0x49, extn2 = 0x0, 
          extn3 = 0x400000000494def3, extn4 = 0x7ffff6e2e99e}
        _func_ = <optimized out>
#17 0x0000555555576276 in main (argc=1, argv=0x7fffffffdeb8) at bin/elementary/test.c:1188
        ret__ = <optimized out>
cedric added a subscriber: cedric.EditedMar 13 2017, 11:35 AM

I have been compiling and testing this over backward in time and so far efl 9 months ago already had the problem. I keep getting the same backtrace :

==2711== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==2711==  Access not within mapped region at address 0x8
==2711==    at 0x17A83D2C: ??? (in /usr/lib/libOSMesa.so.8.0.0)
==2711==    by 0x17A7C401: ??? (in /usr/lib/libOSMesa.so.8.0.0)
==2711==    by 0x17A7BA41: ??? (in /usr/lib/libOSMesa.so.8.0.0)
==2711==    by 0x17A5FAB9: ??? (in /usr/lib/libOSMesa.so.8.0.0)
==2711==    by 0x1CE9C4EC: evgl_glDrawArrays (evas_gl_api_def.h:56)
==2711==    by 0x1ADF1A: draw_gear (test_glview.c:255)
==2711==    by 0x1AE107: gears_draw (test_glview.c:276)
==2711==    by 0x1AE107: render_gears (test_glview.c:283)
==2711==    by 0x1AE107: _draw_gl (test_glview.c:479)
==2711==    by 0x6E3C39A: _render_cb (elm_glview.c:148)
==2711==    by 0x6678801: _event_callback_call (eo_base_class.c:1445)
==2711==    by 0x6678801: _efl_object_event_callback_call (eo_base_class.c:1506)
==2711==    by 0x667360B: efl_event_callback_call (efl_object.eo.c:142)
==2711==    by 0x5D57FF9: _ecore_idle_enterer_call (ecore_idle_enterer.c:48)
==2711==    by 0x5D5C9B7: _ecore_main_loop_iterate_internal (ecore_main.c:2293)

I think we can drop the show stopper here (And still blame @jpeg )

jpeg added a comment.Mar 13 2017, 11:04 PM

Works for me! And it's been working for a while, too.
What driver do you use? Could it be a conflict with mesa itself? I.e. somehow a mesa-based HW driver conflicts with OSmesa, while the NVIDIA proprietary driver doesn't rely on mesa and thus doesn't conflict.

Note that a recent update of mesa / OSMesa completely broke GL rendering in the software engine for me just today. Fixed by c15fee9bccabaef9cf25c63c979bcf1c1b581906 using GetProcAddress instead of dlsym() (this may need a backport?).

jpeg lowered the priority of this task from Showstopper Issues to High.Mar 13 2017, 11:07 PM

@cedric For me, this bug was not present in 1.18.

After updating mesa on arch:
current git and efl 1.19 beta 3 : no crash but it doesn't render correctly here
if I open many GlViewManyGears:
http://www.enlightenment.org/ss/e-58c89f464e5999.56583140.jpg
GLView Gears and ManyGears (it gets black):
http://www.enlightenment.org/ss/e-58c89fa80eb790.49904828.jpg

on 1.18, GLViewManyGears is not working anymore with new mesa (missing symbols)

also the glview GLES 3.x example doesn't show anything, It says the GLES 3.x is not supported although afaik it is (intel drivers)

Just checked and my mesa is pretty old compared to what is recent and used by others (GL_VERSION: OpenGL ES 2.0 Evas GL (3.0 Mesa 11.1.0 (git-525f3c2)))
I blame my problems on my old configuration here.

The essence here is that while it is a important that we solve such things they are not blocking the release as they depend on a old driver combination to make it crash.

raster closed this task as Resolved.Mar 22 2017, 11:16 PM
raster added a subscriber: raster.

WFM... multiple gl views. forcing sw rendering with ELM_ACCEL=none ... mesa 13.0.2 here... i shall take this as a "it's been fixed in mesa since". valgrind doesn't complain for me... i can run many glview tests and no complaining...

Ok it works if you specity ELM_ACCEL=none or ELM_ACCEL=gl.

if you don't specify anything:

  • it works if you set gl in elementary_config
  • it crashes or display garbage if you set no acceleration in elementary_config.

This is with intel drivers btw.
Although fixable with setting the engine in elementary_config or using ELM_ACCEL, there is still a small issue (at least on my machine :) )

works for me with or without ELM_ACCEL set... works on nvidia. works on nouveau... works for me! :)

bu5hm4n reopened this task as Open.Mar 23 2017, 1:05 AM
bu5hm4n added a subscriber: bu5hm4n.

I can just see this when building with open-gl-es... With everything up to date...

bu5hm4n moved this task from Backlog to rendering on the efl board.Jun 10 2018, 12:34 PM
zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:54 AM
zmike edited projects, added efl: rendering; removed Restricted Project.Jun 11 2018, 7:41 AM
zmike lowered the priority of this task from High to Pending on user input.Jun 29 2018, 1:34 PM
zmike added a subscriber: zmike.

Seems fine here.

I don't have segfaults but I still have some windows not rendering correctly in some configurations when playing with opengl=full or opengl=es , ELM_ACCEL etc...
I think if other people don't have segfaults we can close this and open a bug about rendering issues.

zmike closed this task as Resolved.Jul 18 2018, 7:29 AM

Yeah that sounds like T7097.