On Mon, 28 Mar 2016 19:02:54 +0300 Gleb Natapov <[email protected]> said:
> On Mon, Mar 28, 2016 at 10:01:29PM +0900, Carsten Haitzler wrote: > > On Mon, 28 Mar 2016 15:15:09 +0300 Gleb Natapov <[email protected]> said: > > > > it seems you may have old logs or your logs are all over the place. but last > > log: > > > I did not realize e-crashdump.txt is appended to. Is it? it is - rm is to "start clean" :) > > Thread 1 (Thread 0x7febd63e8940 (LWP 8837)): > > #0 0x00007febd1bd1fdd in poll () at ../sysdeps/unix/syscall-template.S:84 > > #1 0x00007febc70bb272 in _xcb_conn_wait (__timeout=-1, __nfds=1, > > #__fds=0x7ffd25e4b020) at /usr/include/bits/poll2.h:46 > > ret = <optimized out> > > fd = {fd = 13, events = 1, revents = 0} > > #2 0x00007febc70bb272 in _xcb_conn_wait (c=c@entry=0x5583a40ece90, > > #cond=cond@entry=0x7ffd25e4b140, vector=vector@entry=0x0, > > #count=count@entry=0x0) at xcb_conn.c:459 > > ret = <optimized out> > > fd = {fd = 13, events = 1, revents = 0} > > #3 0x00007febc70bcc27 in wait_for_reply (c=c@entry=0x5583a40ece90, > > #request=288646, e=e@entry=0x7ffd25e4b210) at xcb_in.c:516 > > cond = {__data = {__lock = 0, __futex = 0, __total_seq = 0, > > __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, > > __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0} > > reader = {request = 288646, data = 0x7ffd25e4b140, next = 0x0} ret = 0x0 > > #4 0x00007febc70bcd31 in xcb_wait_for_reply (c=0x5583a40ece90, > > #request=288646, e=0x7ffd25e4b210) at xcb_in.c:546 > > ret = <optimized out> > > #5 0x00007febcc32d197 in _XReply () at /lib64/libX11.so.6 > > #6 0x00007febcc328bdd in XSync () at /lib64/libX11.so.6 > > #7 0x00007febd20ca97e in ecore_x_sync () at lib/ecore_x/xlib/ecore_x.c:1027 > > #8 0x00005583a225b1a2 in _e_crash () at src/bin/e_signals.c:99 > > #9 0x00007febd52f49f0 in <signal handler called> () > > #at /lib64/libpthread.so.0 10 0x00007febd1bd7c59 in syscall () > > #at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 11 0x00007febba54ec2d in > > #xshmfence_await () at /lib64/libxshmfence.so.1 12 0x00007febbb5d055c in > > #loader_dri3_get_buffers () at /lib64/libGL.so.1 13 0x00007febb9525e4b in > > #intel_update_renderbuffers () at /usr/lib64/dri/i965_dri.so 14 > > #0x00007febb9567888 in intelSetTexBuffer2 () at /usr/lib64/dri/i965_dri.so > > #15 0x00007febbb81c974 in _native_bind_cb (data=<optimized out>, > > #image=<optimized > > #out>) at modules/evas/engines/gl_x11/evas_engine.c:1987 > > re = <optimized out> > > im = <optimized out> > > n = <optimized out> > > __FUNCTION__ = "_native_bind_cb" > > #16 0x00007febb99fb5cd in shader_array_flush (gc=0x5583a42f05f0) at > > #modules/evas/engines/gl_common/evas_gl_context.c:3163 > > > > hangs inside a gl call - binding the native surface. the one just before > > that - same place: > > > > Thread 1 (Thread 0x7f0f7a1a0940 (LWP 1028)): > > #0 0x00007f0f75989fdd in poll () at /lib64/libc.so.6 > > #1 0x00007f0f6ae73272 in _xcb_conn_wait () at /lib64/libxcb.so.1 > > #2 0x00007f0f6ae74c27 in wait_for_reply () at /lib64/libxcb.so.1 > > #3 0x00007f0f6ae74d31 in xcb_wait_for_reply () at /lib64/libxcb.so.1 > > #4 0x00007f0f700e5197 in _XReply () at /lib64/libX11.so.6 > > #5 0x00007f0f700e0bdd in XSync () at /lib64/libX11.so.6 > > #6 0x0000563c7297c1a2 in _e_crash () > > #7 0x00007f0f790ac9f0 in <signal handler called> () > > #at /lib64/libpthread.so.0 8 0x00007f0f7598fc59 in syscall () > > #at /lib64/libc.so.6 9 0x00007f0f5e306c2d in xshmfence_await () > > #at /lib64/libxshmfence.so.1 10 0x00007f0f5f38855c in > > #loader_dri3_get_buffers () at /lib64/libGL.so.1 > > > > and before that: > > > > Thread 1 (Thread 0x7fb523c34940 (LWP 14681)): > > #0 0x00007fb51f41dfdd in poll () at /lib64/libc.so.6 > > #1 0x00007fb514907272 in _xcb_conn_wait () at /lib64/libxcb.so.1 > > #2 0x00007fb514908c27 in wait_for_reply () at /lib64/libxcb.so.1 > > #3 0x00007fb514908d31 in xcb_wait_for_reply () at /lib64/libxcb.so.1 > > #4 0x00007fb519b79197 in _XReply () at /lib64/libX11.so.6 > > #5 0x00007fb519b74bdd in XSync () at /lib64/libX11.so.6 > > #6 0x000055a5fa6301a2 in _e_crash () > > #7 0x00007fb522b409f0 in <signal handler called> () > > #at /lib64/libpthread.so.0 8 0x00007fb51f423c59 in syscall () > > #at /lib64/libc.so.6 9 0x00007fb507d9ac2d in xshmfence_await () > > #at /lib64/libxshmfence.so.1 10 0x00007fb508e1c55c in > > #loader_dri3_get_buffers () at /lib64/libGL.so.1 11 0x00007fb506d71e4b in > > #intel_update_renderbuffers () at /usr/lib64/dri/i965_dri.so 12 > > #0x00007fb506db3888 in intelSetTexBuffer2 () at /usr/lib64/dri/i965_dri.so > > #13 0x00007fb509068974 in _native_bind_cb () > > #at /usr/lib64/evas/modules/engines/gl_x11/v-1.16/module.so > > > > so last 3 in a row are hanging in libGL (which is your driver for 3d) in > > trying to simply SET a native surface (pixmap) ass the source to render > > from. not sure what to say... nothing e can do about this? libGL is trying > > to sync with a fence with likely the xserver and it's not working. this is > > beyond e or efl's control - you seem to have a driver/xserver bug we've > > managed to hit on. :) > > > Ah, story of my life :( :( at leas thats what the logs say. if that is where e hangs ad you are ding a: killall -SEGV enlightenment which i guess you are from the bt - then the segv handler is being triggered during that wait. in fact the XSync is even being blocked and going nowhere. no reply from xserver. 2 things could be at fault. 1. xserver bug (or driver bug inside xserver) 2. someone has the xserver grabbed. it could be e has the server grabbed and your gl driver is using a SEPARATE display connection other than e/gl's main one (you initialize your gl context from your display connection). this can be a deadlock. this generally is poor/bad design inside the driver to do this because it doesn't use the display connection it is told to. i would class this as a driver bug.. anyway under e's settings -> look -> compositor -> advanced -> misc is "grab server during draw". this is there to try and minimize "tearing" by locking out applications from drawing while the compositor is busy compositing or using their pixmaps as sources. this doesn't guarantee it but it's a try. is this on or off? if on - try turn it off. other than this i know of no grab from e that would be held while e draws so it likely is #1 above. > On the other note IIRC when older version crashed they remembered > windows positions and after pressing F1 desktop returned to the same > state. With 0.20 it remembers a virtual desktop a windows belongs to, > but it changes its placement and forget that window is maximized, so it > cannot be de-maximized afterwords (or so I noticed for xterm at least). i think that was a bug to do with screen reconfiguration and losing/recovering a screen. it has since been fixed in git. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
