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?
> 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 :(
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).
--
Gleb.
------------------------------------------------------------------------------
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
