On 03/29/2016 02:32 AM, Gleb Natapov wrote:
> 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?
> 

Yeah it is, which can be good or bad, It would be nice if there was a
timestamp appended between.

>> 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
> 

-- 
Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                           Adeliade Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

------------------------------------------------------------------------------
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

Reply via email to