local variable and args in crash thread:

(gdb) info locals
color = {0xb2298100 <error: Cannot access memory at address 0xb2298100>, 0xc01064b3 <error: Cannot access memory at address 0xc01064b3>, 
  0xb7d6de89 <ioctl+25> "[=\001\360\377\377\017\203\213\227\363\377\303f\220f\220f\220f\220f\220e\203=\f", 0xb7c72c0b <__pthread_mutex_unlock_usercnt+11> "\201\307\365\003\001", 
  0xb715b000 "\360]\225", 0xb2d6a008 "0\303\017\b\260y,\b", 0xb2d6a1fc "", 0xb2d6a868 "\300\367\021\b\360B-\b\360B-\b\300\367\021\b\230X-\b\230X-\b\300\367\021\b0r-\b0r-\b"}
depth = <optimized out>
i = <optimized out>
stride = {4096, 3000410620, 134911960, 0, 3066076233, 0, 2621440, 3084396197}
depth_stride = <optimized out>
scene = 0xb2d6a008
inputs = 0x812c030
state = 0x811f7c0
variant = 0x8202c30
tile_x = 64
tile_y = 448
x = 0
y = 12
(gdb) info args
task = 0x80a9ab4
arg = {shade_tile = 0x812c030, triangle = {tri = 0x812c030, plane_mask = 10}, set_state = 0x812c030, clear_rb = 0x812c030, clear_zstencil = {value = 43085119536, 
    mask = 18446744030745985025}, state = 0x812c030, fence = 0x812c030, query_obj = 0x812c030}

This is with Weston's DRM-backend, right?

I'll just point out that this has nothing to do with Wayland. even if it was a Weston bug which I doubt. Any application that runs on KMS and uses kms_swrast_dri.so should be able to hit the same crash.

However, I'm not sure if this should be a llvmpipe or EGL/KMS bug, or what component in Bugzilla that would match.

When does this happen btw.?

Is it on Weston startup, or later, or perhaps when you try to run any application using OpenGL under Weston?

So, it crashed in the jit fragment shader code.
Could you tell what the fb size was (the values from scene->fb in lp_rast_shade_tile, possibly the ones from the (first) color and zbuffer themselves)? I was actually wondering at some point what really ensures if buffers have sufficient alignment - buffers allocated within llvmpipe will always have that, but the front/back buffers are allocated - elsewhere (they need to be allocated to 4x4 alignment).
Other than that I'm not sure what the problem could be. You could try some x/i variant to get the disassembly, which should tell you if it was framebuffer access or not (as fb accesses are towards the end of the jit code, and they'll show some fairly typical patterns).

> This is with Weston's DRM-backend, right? 
I think so . I'm using GMA500 driver and didn't launch X11, just run weston from terminal.

> When does this happen btw.?
> 
> Is it on Weston startup, or later, or perhaps when you try to run any
> application using OpenGL under Weston?

Weston startup.

It is an alignment problem in the code. I fixed it with:

https://chromium-review.googlesource.com/#/c/332681/2/media-libs/mesa/files/10.5-lp_rast-Remove-alignment-constraints.patch

Feel free to try locally and see if it helps for you.

(In reply to Stephane Marchesin from comment #6)
> It is an alignment problem in the code. I fixed it with:
> 
> https://chromium-review.googlesource.com/#/c/332681/2/media-libs/mesa/files/
> 10.5-lp_rast-Remove-alignment-constraints.patch
> 
> Feel free to try locally and see if it helps for you.

memory access is movdqa, maybe this is same problem. but these code already changed to jit so patch didn't work.

(In reply to Roland Scheidegger from comment #4)
> So, it crashed in the jit fragment shader code.
> Could you tell what the fb size was (the values from scene->fb in
> lp_rast_shade_tile, possibly the ones from the (first) color and zbuffer
> themselves)? I was actually wondering at some point what really ensures if
> buffers have sufficient alignment - buffers allocated within llvmpipe will
> always have that, but the front/back buffers are allocated - elsewhere (they
> need to be allocated to 4x4 alignment).

my laptop is GMA500, resolution 1024x600

scene->fb value in crash stack
{width = 1024, height = 600, nr_cbufs = 1, cbufs = {0x8141e28, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, zsbuf = 0x0}

so maybe cbufs[0] isn't 16 byte aligned?

> Other than that I'm not sure what the problem could be. You could try some
> x/i variant to get the disassembly, which should tell you if it was
> framebuffer access or not (as fb accesses are towards the end of the jit
> code, and they'll show some fairly typical patterns).

crash address and asm:
0xb755e633      movdqa %ecx,%eax,1),%xmm2
0xb755e638      movdqa  %xmm7,%xmm1
0xb755e63c      movdqa %xmm2,0x30(%esp
0xb755e642      movapd %xmm0,0x80(%esp)
0xb755e64b      movdqa %xmm2,%xmm0
0xb755e64f      pxor   0xb7fc2080,%xmm1  
0xb755e657      punpcklbw %xmm3,%xmm0 
0xb755e65b      movdqa %xmm1,%xmm7
0xb755e65f      punpckhbw %xmm3,%xmm1
0xb755e663      punpcklbw %xmm3,%xmm7
0xb755e667      pmullw %xmm0,%xmm7
0xb755e66b      movdqa %xmm2,%xmm0 
0xb755e66f      punpckhbw %xmm3,%xmm0 
0xb755e673      pxor   %xmm3,%xmm3 
0xb755e677      pmullw %xmm0,%xmm1
0xb755e67b      cvtps2dq 0x130(%esp),%xmm0 
0xb755e684      movdqa %xmm7,0x100(%esp)
0xb755e68d      movaps 0xb7fc2040,%xmm7 
0xb755e694      movdqa %xmm1,0x140(%esp) 



(gdb) info registers ecx
ecx            0xb210c000       -1307525120
(gdb) info registers eax
eax            0x1000   4096


I also found sometimes it crashes at lp_rast.c:457

(In reply to comicfans44 from comment #8)
> (In reply to Roland Scheidegger from comment #4)
> > So, it crashed in the jit fragment shader code.
> > Could you tell what the fb size was (the values from scene->fb in
> > lp_rast_shade_tile, possibly the ones from the (first) color and zbuffer
> > themselves)? I was actually wondering at some point what really ensures if
> > buffers have sufficient alignment - buffers allocated within llvmpipe will
> > always have that, but the front/back buffers are allocated - elsewhere (they
> > need to be allocated to 4x4 alignment).
> 
> my laptop is GMA500, resolution 1024x600
> 
> scene->fb value in crash stack
> {width = 1024, height = 600, nr_cbufs = 1, cbufs = {0x8141e28, 0x0, 0x0,
> 0x0, 0x0, 0x0, 0x0, 0x0}, zsbuf = 0x0}
> 
> so maybe cbufs[0] isn't 16 byte aligned?
Well the regs below seem to indicate the access was aligned, and width/height are ok too.


> 
> > Other than that I'm not sure what the problem could be. You could try some
> > x/i variant to get the disassembly, which should tell you if it was
> > framebuffer access or not (as fb accesses are towards the end of the jit
> > code, and they'll show some fairly typical patterns).
> 
> crash address and asm:
> 0xb755e633      movdqa %ecx,%eax,1),%xmm2
> 0xb755e638      movdqa  %xmm7,%xmm1
> 0xb755e63c      movdqa %xmm2,0x30(%esp
> 0xb755e642      movapd %xmm0,0x80(%esp)
> 0xb755e64b      movdqa %xmm2,%xmm0
> 0xb755e64f      pxor   0xb7fc2080,%xmm1  
> 0xb755e657      punpcklbw %xmm3,%xmm0 
> 0xb755e65b      movdqa %xmm1,%xmm7
> 0xb755e65f      punpckhbw %xmm3,%xmm1
> 0xb755e663      punpcklbw %xmm3,%xmm7
> 0xb755e667      pmullw %xmm0,%xmm7
> 0xb755e66b      movdqa %xmm2,%xmm0 
> 0xb755e66f      punpckhbw %xmm3,%xmm0 
> 0xb755e673      pxor   %xmm3,%xmm3 
> 0xb755e677      pmullw %xmm0,%xmm1
> 0xb755e67b      cvtps2dq 0x130(%esp),%xmm0 
> 0xb755e684      movdqa %xmm7,0x100(%esp)
> 0xb755e68d      movaps 0xb7fc2040,%xmm7 
> 0xb755e694      movdqa %xmm1,0x140(%esp)

That could be fb blend (due to the pmullw) but it's difficult to tell (could be texturing too).

In your original post it actually looks like gdb couldn't access the color buffer but I'm not sure if that's just gdb not quite figuring out the correct address (there's lots of optimized out stuff too so probably not proper debug build?) or if that's really because the address isn't accessible. If it's the latter that would suggest the buffer simply may have disappeared (buffers allocated by llvmpipe are refcounted, but back buffers are allocated and freed elsewhere, so outside of llvmpipe's control.

In any case, this indeed looks like a separate issue to the bug Stephane pointed out, and in contrast to that issue I don't think anything really changed there directly in llvmpipe for ages. Could you bisect?

Actually the asm snipped might be something different. You could try printing the whole jit prog (from the address from the caller, or use GALLIVM_DEBUG=asm).
Using valgrind could possibly tell you some more if it's using some buffer which was freed (if that is actually the case, this problem shouldnt' be restricted to 32bit).
Another random thought is that spilling sse regs in llvm could be broken (again) due to non-aligned stack pointer (albeit in this case gdb would indicate the wrong instruction, but could be the one immediately before). Seems a bit unlikely.

FWIW the bug Stephane mentioned (which you'd hit near certainly too, unless you built without sse2 enabled, and the compositor itself might not hit it) is fixed by bb2c5e657b5f4c55bcec49a8d96f352ed4c1e013.

with 	bb2c5e657b5f4c55bcec49a8d96f352ed4c1e013 
lp_rast.c:352 didn't crash

but still crash at lp_rast.c:457

0xb7fc26f3 in ?? ()
0xb272a22b in lp_rast_shade_quads_mask (task=0xb5834a08, inputs=0xac5023a0, x=108, y=64, mask=12) at lp_rast.c:457
#2  0xb272b285 in do_block_4_1 (c=<optimized out>, y=<optimized out>, x=<optimized out>, plane=<optimized out>, tri=<optimized out>, task=<optimized out>) at lp_rast_tri_tmp.h:67
#3  do_block_16_1 (c=<synthetic pointer>, y=<optimized out>, x=<optimized out>, plane=0xaf058074, tri=0xac5023a0, task=0xb5834a08) at lp_rast_tri_tmp.h:152
#4  lp_rast_triangle_1 (task=0xb5834a08, arg=...) at lp_rast_tri_tmp.h:305
#5  0xb27297b1 in do_rasterize_bin (bin=<optimized out>, x=<optimized out>, y=<optimized out>, task=0xb5834a08) at lp_rast.c:609
#6  rasterize_bin (y=<optimized out>, x=<optimized out>, bin=<optimized out>, task=0xb5834a08) at lp_rast.c:628
#7  rasterize_scene (task=task@entry=0xb5834a08, scene=<optimized out>) at lp_rast.c:688
#8  0xb2729f3a in thread_function (init_data=0xb5834a08) at lp_rast.c:828
#9  0xb2729d55 in impl_thrd_routine (p=0xb5e02bb0) at ../../../../include/c11/threads_posix.h:87
#10 0xb7b02400 in __asan::AsanThread::ThreadStart (this=0xb632c000, os_id=935) at /build/gcc/src/gcc-5-20160209/libsanitizer/asan/asan_thread.cc:169
#11 0xb7a8ff38 in asan_thread_start (arg=0xb632c000) at /build/gcc/src/gcc-5-20160209/libsanitizer/asan/asan_interceptors.cc:169
#12 0xb771f291 in start_thread () from target:/usr/lib/libpthread.so.0



info args:
task = 0xb5834a08
inputs = 0xac5023a0
x = 108
y = 64
mask = 12



(gdb) p *task
$4 = {bin = 0xb55a1018, state = 0xac500900, scene = 0xb55a0800, x = 64, y = 64, width = 64, height = 64, color_tiles = {0xa8ec0100 <error: Cannot access memory at address 0xa8ec0100>, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, depth_tile = 0x0, rast = 0xb5834900,
  thread_index = 1, thread_data = {cache = 0xb3011900, vis_counter = 0, raster_state = {viewport_index = 0}}, ps_invocations = 1, ps_inv_multiplier = 0 '\000', work_ready = {mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {
          __elision_data = {__espins = 0, __elision = 0}, __list = {__next = 0x0}}}, __size = '\000' <repeats 23 times>, __align = 0}, cond = {__data = {__lock = 0, __futex = 2, __total_seq = 1, __wakeup_seq = 1, __woken_seq = 1, __mutex = 0xb5834a6c, __nwaiters = 0,
        __broadcast_seq = 0}, __size = "\000\000\000\000\002\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000lJ\203\265", '\000' <repeats 11 times>, __align = 8589934592}, counter = 0}, work_done = {mutex = {
      __data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__elision_data = {__espins = 0, __elision = 0}, __list = {__next = 0x0}}}, __size = '\000' <repeats 23 times>, __align = 0}, 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}, counter = 0}}





p *inputs
$2 = {frontfacing = 0, disable = 0, opaque = 0, pad0 = 0, stride = 16, layer = 0, viewport_index = 0}


info locals:
state = 0xac500900
variant = 0xb4c18380
scene = <optimized out>
color = {0xa8ec01b0 <error: Cannot access memory at address 0xa8ec01b0>, 0x3f800000 "", 0x3f800000 "", 0x3f800000 "", 0xa8ebcfb0 <error: Cannot access memory at address 0xa8ebcfb0>, 0x3f800000 "", 0x3f800000 "", 0x3f800000 ""}
stride = {4096, 1065353216, 1065353216, 1065353216, 4096, 2890933152, 3032580992, 3045280264}
depth = <optimized out>
depth_stride = 2936372688
i = <optimized out>


crash address asm:


0xb7fc26f3      movdqa (%ecx,%eax,2),%xmm1                           
0xb7fc26f8      movapd %xmm0,0x170(%esp)                             
0xb7fc2701      pcmpeqd %xmm0,%xmm0                                  
0xb7fc2705      andps  0xb7fcf050,%xmm4                              
0xb7fc270c      pxor   %xmm0,%xmm5                                   
0xb7fc2710      movdqa %xmm1,%xmm0                                   
0xb7fc2714      movdqa %xmm5,%xmm2                                   
0xb7fc2718      punpcklbw %xmm3,%xmm0                                
0xb7fc271c      punpcklbw %xmm3,%xmm2                                
0xb7fc2720      pmullw %xmm0,%xmm2                                   
0xb7fc2724      cvtps2dq 0xe0(%esp),%xmm0                            
0xb7fc272d      punpckhbw %xmm3,%xmm5                                
0xb7fc2731      movdqa %xmm2,0xb0(%esp)                              
0xb7fc273a      movapd %xmm0,0xe0(%esp)                              
0xb7fc2743      movdqa %xmm1,%xmm0                                   
0xb7fc2747      punpckhbw %xmm3,%xmm0                                
0xb7fc274b      pmullw %xmm0,%xmm5                                   
0xb7fc274f      cvtps2dq 0x120(%esp),%xmm0                           
0xb7fc2758      movdqa %xmm1,0xd0(%esp)                              
0xb7fc2761      pshufd $0x4e,%xmm4,%xmm1                             
0xb7fc2766      movapd %xmm0,0x120(%esp)                             
0xb7fc276f      cvtps2dq 0xf0(%esp),%xmm0                            
0xb7fc2778      pshufd $0xe7,%xmm4,%xmm2                             
0xb7fc277d      punpcklwd %xmm2,%xmm1                                
0xb7fc2781      movapd %xmm0,(%esp)                                  
0xb7fc2786      pshufd $0xe5,%xmm4,%xmm0                             
0xb7fc278b      punpcklwd %xmm0,%xmm4                                
0xb7fc278f      punpcklbw %xmm1,%xmm4                                
0xb7fc2793      pshufb 0xb7fcf060,%xmm4                              
0xb7fc279c      movdqa (%ecx,%edx,1),%xmm1                           
0xb7fc27a1      movdqa %xmm1,0xf0(%esp)                              
0xb7fc27aa      movdqa %xmm1,%xmm0                                   
0xb7fc27ae      pxor   0xb7fcf080,%xmm4 


(gdb) info registers ecx
ecx            0xa8ec01b0       -1460928080
(gdb) info registers eax
eax            0x1000   4096

(In reply to comicfans44 from comment #12)
> but still crash at lp_rast.c:457
> 
> 0xb7fc26f3 in ?? ()
[...]
> 
> info locals:
> state = 0xac500900
> variant = 0xb4c18380
> scene = <optimized out>
> color = {0xa8ec01b0 <error: Cannot access memory at address 0xa8ec01b0>,


>
> 
> crash address asm:
> 
> 
> 0xb7fc26f3      movdqa (%ecx,%eax,2),%xmm1                           
[...]
> 
> (gdb) info registers ecx
> ecx            0xa8ec01b0       -1460928080
> (gdb) info registers eax
> eax            0x1000   4096


I wonder if 0xa8ec01b0 is some sort of funky device memory, or if that device memory was destroyed before llvmpipe was done.


After all this is SwapBuffers path.

(In reply to Jose Fonseca from comment #13)
> I wonder if 0xa8ec01b0 is some sort of funky device memory, or if that
> device memory was destroyed before llvmpipe was done.
> 
> After all this is SwapBuffers path.

That's very likely, isn't it?

comicfans44, can you confirm the dri module used, I would assume it is kms_swrast_dri.so? EGL_LOG_LEVEL=debug environment variable will fish it out.

This is triggered by Weston running on bare VT, so likely the DRM-backend (which could be confirmed from Weston's output/logs), and since KMS is involved, I would guess that kms_swrast_dri.so or EGL is using DRM dumb buffers as targets. Well, if it is not using a shadow buffer. I don't know how kms_swrast_dri.so works.

Maybe the bug is in the KMS glue code rather than llvmpipe?

(In reply to Pekka Paalanen from comment #14)
> (In reply to Jose Fonseca from comment #13)
> > I wonder if 0xa8ec01b0 is some sort of funky device memory, or if that
> > device memory was destroyed before llvmpipe was done.
> > 
> > After all this is SwapBuffers path.
> 
> That's very likely, isn't it?
> 
> comicfans44, can you confirm the dri module used, I would assume it is
> kms_swrast_dri.so? EGL_LOG_LEVEL=debug environment variable will fish it out.
> 

with EGL_LOG_LEVEL=debug weston print log as follows(maybe including weston log )

[22:11:38.630] weston 1.10.0
               http://wayland.freedesktop.org
               Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.10.0
               Build: 1.9.93-2-gd45de28 configure.ac: bump to version 1.10.0 for the official release (2016-02-16 12:37:43 -0800)
[22:11:38.639] OS: Linux, 4.4.5-1-ARCH, #1 SMP PREEMPT Thu Mar 10 07:54:30 CET 2016, i686
[22:11:38.640] Starting with no config file.
[22:11:38.643] Output repaint window is 7 ms maximum.
[22:11:38.643] Loading module '/usr/lib/weston/drm-backend.so'
[22:11:39.930] initializing drm backend
[22:11:39.943] logind: session control granted
[22:11:39.952] using /dev/dri/card0
[22:11:39.952] Loading module '/usr/lib/weston/gl-renderer.so'
pci id for fd 14: 8086:8108, driver (null)
[22:11:59.302] EGL client extensions: EGL_EXT_client_extensions
               EGL_EXT_platform_base EGL_EXT_platform_wayland
               EGL_EXT_platform_x11 EGL_KHR_client_get_all_proc_addresses
               EGL_MESA_platform_gbm
libEGL debug: added egl_dri2 to module array
libEGL debug: the best driver is DRI2
[22:11:59.305] warning: EGL_EXT_swap_buffers_with_damage not supported. Performance could be affected.
[22:11:59.344] input device 'Video Bus', /dev/input/event0 is tagged by udev as: Keyboard
[22:11:59.344] input device 'Video Bus', /dev/input/event0 is a keyboard
[22:11:59.348] input device 'Power Button', /dev/input/event5 is tagged by udev as: Keyboard
[22:11:59.349] input device 'Power Button', /dev/input/event5 is a keyboard
[22:11:59.354] input device 'Lid Switch', /dev/input/event3 not tagged as input device
[22:11:59.354] failed to create input device '/dev/input/event3'.
[22:11:59.361] input device 'Sleep Button', /dev/input/event4 is tagged by udev as: Keyboard
[22:11:59.361] input device 'Sleep Button', /dev/input/event4 is a keyboard
[22:11:59.365] input device 'HDA Intel MID Mic', /dev/input/event9 not tagged as input device
[22:11:59.366] failed to create input device '/dev/input/event9'.
[22:11:59.371] input device 'HDA Intel MID Headphone', /dev/input/event10 not tagged as input device
[22:11:59.373] failed to create input device '/dev/input/event10'.
[22:11:59.434] input device 'AsusTek, Inc. MultiTouch', /dev/input/event2 is tagged by udev as: Touchscreen
[22:11:59.435] input device 'AsusTek, Inc. MultiTouch', /dev/input/event2 is a touch device
[22:11:59.444] input device 'USB 2.0 Camera', /dev/input/event11 is tagged by udev as: Keyboard
[22:11:59.444] input device 'USB 2.0 Camera', /dev/input/event11 is a keyboard
[22:11:59.451] input device 'Eee PC WMI hotkeys', /dev/input/event7 is tagged by udev as: Keyboard
[22:11:59.451] input device 'Eee PC WMI hotkeys', /dev/input/event7 is a keyboard
[22:11:59.456] input device 'AT Translated Set 2 keyboard', /dev/input/event1 is tagged by udev as: Keyboard
[22:11:59.456] input device 'AT Translated Set 2 keyboard', /dev/input/event1 is a keyboard
[22:11:59.461] input device 'SynPS/2 Synaptics TouchPad', /dev/input/event8 is tagged by udev as: Touchpad Touchscreen
[22:11:59.461] input device 'SynPS/2 Synaptics TouchPad', /dev/input/event8 is a touchpad
[22:11:59.480] input device 'PC Speaker', /dev/input/event6 not tagged as input device
[22:11:59.481] failed to create input device '/dev/input/event6'.
[22:11:59.631] EGL version: 1.4 (DRI2)
[22:11:59.632] EGL vendor: Mesa Project
[22:11:59.632] EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2 OpenGL_ES3 
[22:11:59.632] EGL extensions: EGL_EXT_buffer_age EGL_KHR_create_context
               EGL_KHR_get_all_proc_addresses EGL_KHR_gl_renderbuffer_image
               EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image
               EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap
               EGL_KHR_surfaceless_context EGL_MESA_configless_context
               EGL_MESA_image_dma_buf_export
[22:11:59.632] GL version: OpenGL ES 3.0 Mesa 11.3.0-devel (git-b566317)
[22:11:59.632] GLSL version: OpenGL ES GLSL ES 3.00
[22:11:59.632] GL vendor: VMware, Inc.
[22:11:59.632] GL renderer: Gallium 0.4 on llvmpipe (LLVM 3.7, 128 bits)
[22:11:59.632] GL extensions: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays
               GL_EXT_texture_compression_dxt1 GL_EXT_texture_format_BGRA8888
               GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24
               GL_OES_element_index_uint GL_OES_fbo_render_mipmap
               GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives
               GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_float
               GL_OES_texture_float_linear GL_OES_texture_half_float
               GL_OES_texture_half_float_linear GL_OES_texture_npot
               GL_EXT_texture_sRGB_decode GL_OES_EGL_image
               GL_OES_depth_texture GL_OES_packed_depth_stencil
               GL_EXT_texture_type_2_10_10_10_REV GL_OES_get_program_binary
               GL_APPLE_texture_max_level GL_EXT_discard_framebuffer
               GL_EXT_read_format_bgra GL_NV_fbo_color_attachments
               GL_OES_EGL_image_external GL_OES_EGL_sync
               GL_OES_vertex_array_object GL_ANGLE_texture_compression_dxt3
               GL_ANGLE_texture_compression_dxt5 GL_EXT_texture_rg
               GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer
               GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil
               GL_EXT_draw_buffers GL_EXT_map_buffer_range GL_KHR_debug
               GL_OES_depth_texture_cube_map GL_OES_surfaceless_context
               GL_EXT_color_buffer_float GL_EXT_separate_shader_objects
               GL_EXT_shader_integer_mix GL_EXT_draw_elements_base_vertex
               GL_EXT_texture_border_clamp GL_KHR_context_flush_control
               GL_OES_draw_elements_base_vertex GL_OES_texture_border_clamp
               GL_OES_texture_stencil8 GL_EXT_blend_func_extended
[22:11:59.633] GL ES 2 renderer features:
               read-back format: BGRA
               wl_shm sub-image to texture: yes
               EGL Wayland extension: no
[22:11:59.633] Chosen EGL config details:
               RGBA bits: 8 8 8 0
               swap interval range: 0 - 0
[22:11:59.634] Initialized backlight, device /sys/class/backlight/acpi_video0
[22:11:59.636] EDID data 'CMO', '', ''
[22:11:59.636] Output LVDS-1, (connector 24, crtc 21)
               mode 1024x600@60.0, preferred, current
[22:11:59.759] Compositor capabilities:
               arbitrary surface rotation: yes
               screen capture uses y-flip: yes
               presentation clock: CLOCK_MONOTONIC, id 1
[22:11:59.760] Loading module '/usr/lib/weston/desktop-shell.so'
[22:11:59.958] launching '/usr/lib/weston/weston-keyboard'
Detaching from process 1046
[22:11:59.987] launching '/usr/lib/weston/weston-desktop-shell'
Detaching from process 1047
Failed to process Wayland connection: Connection reset by peer
failed to create display: Connection reset by peer
Failed to process Wayland connection: Connection reset by peer
failed to create display: Connection reset by peer





info sharedlibrary shows only one so with dri suffix which is 
/usr/lib/xorg/modules/dri/kms_swrast_dri.so



0xb7fdc940  0xb7ff538d  Yes (*)     target:/lib/ld-linux.so.2
0xb7a75de0  0xb7b28fe4  Yes         target:/usr/lib/libasan.so.2
0xb7a52e00  0xb7a58c34  Yes (*)     target:/usr/lib/libwayland-server.so.0
0xb79a5430  0xb7a31244  Yes (*)     target:/usr/lib/libpixman-1.so.0
0xb795ea40  0xb7979cc4  Yes (*)     target:/usr/lib/libxkbcommon.so.0
0xb79461c0  0xb794c494  Yes (*)     target:/usr/lib/libunwind.so.8
0xb78f4590  0xb792bb97  Yes (*)     target:/usr/lib/libm.so.6
0xb78eba30  0xb78ec961  Yes (*)     target:/usr/lib/libdl.so.2
0xb774d670  0xb78789ab  Yes (*)     target:/usr/lib/libc.so.6
0xb771d850  0xb772af21  Yes (*)     target:/usr/lib/libpthread.so.0
0xb760e2f0  0xb76c2d54  Yes         target:/usr/lib/libstdc++.so.6
0xb7586080  0xb759b695  Yes         target:/usr/lib/libgcc_s.so.1
0xb757c1b0  0xb7580584  Yes (*)     target:/usr/lib/libffi.so.6
0xb7573840  0xb757700c  Yes (*)     target:/usr/lib/librt.so.1
0xb7548450  0xb7561e94  Yes (*)     target:/usr/lib/liblzma.so.5
0xb63448d0  0xb6368a44  Yes         target:/usr/lib/weston/drm-backend.so
0xb63083a0  0xb631a6b4  Yes (*)     target:/usr/lib/libudev.so.1
0xb61f2a70  0xb61f8534  Yes         target:/usr/lib/libgbm.so.1
0xb61eab90  0xb61ed3aa  Yes (*)     target:/usr/lib/libmtdev.so.1
0xb61c0c70  0xb61d8474  Yes (*)     target:/usr/lib/libinput.so.10
0xb61abfe0  0xb61b4264  Yes (*)     target:/usr/lib/libdrm.so.2
0xb6123c30  0xb617f754  Yes (*)     target:/usr/lib/libsystemd.so.0
0xb5faf010  0xb5fdd0f4  Yes (*)     target:/usr/lib/libdbus-1.so.3
0xb7fc3960  0xb7fc41d4  Yes (*)     target:/usr/lib/libva-drm.so.1
0xb5f83e50  0xb5f927f4  Yes (*)     target:/usr/lib/libva.so.1
0xb6300e20  0xb63027e1  Yes (*)     target:/usr/lib/libcap.so.2
0xb6103690  0xb610fed4  Yes (*)     target:/usr/lib/libresolv.so.2
0xb5f5b300  0xb5f72f64  Yes (*)     target:/usr/lib/libexpat.so.1
0xb5f4df80  0xb5f526e4  Yes (*)     target:/usr/lib/libwayland-client.so.0
0xb5f3b730  0xb5f40e14  Yes (*)     target:/usr/lib/libevdev.so.2
0xb5f2e480  0xb5f32224  Yes (*)     target:/usr/lib/libwacom.so.2
0xb5f1ac10  0xb5f27794  Yes (*)     target:/usr/lib/liblz4.so.1
0xb5d56140  0xb5dbc2e4  Yes (*)     target:/usr/lib/libgcrypt.so.20
0xb5f050b0  0xb5f0f0c4  Yes (*)     target:/usr/lib/libgpg-error.so.0
0xb5d47ca0  0xb5d4af34  Yes (*)     target:/usr/lib/libgudev-1.0.so.0
0xb5bab740  0xb5bdd414  Yes (*)     target:/usr/lib/libgobject-2.0.so.0
0xb42ef7f0  0xb436a654  Yes (*)     target:/usr/lib/libglib-2.0.so.0
0xb4142390  0xb421d714  Yes (*)     target:/usr/lib/libgio-2.0.so.0
0xb5b2f030  0xb5b7b8f4  Yes (*)     target:/usr/lib/libpcre.so.1
0xb5d40cd0  0xb5d41d74  Yes (*)     target:/usr/lib/libgmodule-2.0.so.0
0xb5d29a00  0xb5d3620d  Yes (*)     target:/usr/lib/libz.so.1
0xb5d0a500  0xb5d1c504  Yes         target:/usr/lib/weston/gl-renderer.so
0xb59d1a90  0xb59eb0f4  Yes         target:/usr/lib/libEGL.so.1
0xb5d037c0  0xb5d03902  Yes         target:/usr/lib/libGLESv2.so.2
0xb5f00450  0xb5f005b2  Yes (*)     target:/usr/lib/libX11-xcb.so.1
0xb2cc4310  0xb2d4ee14  Yes (*)     target:/usr/lib/libX11.so.6
0xb5b29450  0xb5b2ab84  Yes (*)     target:/usr/lib/libxcb-dri2.so.0
0xb5b24a10  0xb5b25404  Yes (*)     target:/usr/lib/libxcb-dri3.so.0
0xb5b20970  0xb5b21394  Yes (*)     target:/usr/lib/libxcb-present.so.0
0xb5b14f20  0xb5b1a5f4  Yes (*)     target:/usr/lib/libxcb-randr.so.0
0xb5b09010  0xb5b0bc84  Yes (*)     target:/usr/lib/libxcb-xfixes.so.0
---Type <return> to continue, or q <return> to quit---
0xb59c4cb0  0xb59c8ac4  Yes (*)     target:/usr/lib/libxcb-render.so.0
0xb5b02c30  0xb5b03a74  Yes (*)     target:/usr/lib/libxcb-shape.so.0
0xb59bb990  0xb59bdd84  Yes (*)     target:/usr/lib/libxcb-sync.so.1
0xb599b9c0  0xb59ad364  Yes (*)     target:/usr/lib/libxcb.so.1
0xb5990710  0xb5990aa4  Yes (*)     target:/usr/lib/libxshmfence.so.1
0xb5978140  0xb5978e14  Yes         target:/usr/lib/libglapi.so.0
0xb5970ab0  0xb59718d4  Yes (*)     target:/usr/lib/libXau.so.6
0xb596a000  0xb596bb94  Yes (*)     target:/usr/lib/libXdmcp.so.6
0xb20877a0  0xb2782444  Yes         target:/usr/lib/xorg/modules/dri/kms_swrast_dri.so
0xb5932220  0xb5953e04  Yes (*)     target:/usr/lib/libnettle.so.6
0xb5908200  0xb591bc14  Yes (*)     target:/usr/lib/libdrm_intel.so.1
0xb57f7410  0xb57fb944  Yes (*)     target:/usr/lib/libdrm_nouveau.so.2
0xb57e9220  0xb57f1404  Yes (*)     target:/usr/lib/libdrm_radeon.so.1
0xb57de2f0  0xb57e31f4  Yes (*)     target:/usr/lib/libdrm_amdgpu.so.1
0xb57c34e0  0xb57d3ea4  Yes (*)     target:/usr/lib/libelf.so.1
0xafb1d3f0  0xb1106544  Yes (*)     target:/usr/lib/libLLVM.so.3.7
0xb57b5a90  0xb57ba9f4  Yes (*)     target:/usr/lib/libpciaccess.so.0
0xb5781a80  0xb579bd04  Yes (*)     target:/usr/lib/../lib/libedit.so.0
0xb5719c50  0xb5755944  Yes (*)     target:/usr/lib/../lib/libncursesw.so.6
0xb63265a0  0xb6329334  Yes (*)     target:/usr/lib/libtxc_dxtn.so
0xb555f510  0xb5589864  Yes         target:/usr/lib/weston/desktop-shell.so

(In reply to Jose Fonseca from comment #13)

> 
> I wonder if 0xa8ec01b0 is some sort of funky device memory, or if that
> device memory was destroyed before llvmpipe was done.
> 
> 

How can I help to identify if this is the root cause ? if I build mesa with address sanitizer ,can I force mesa not to use jit to let address sanitizer to find if this is a heap-use-after-free ?

(In reply to comicfans44 from comment #16)

> 
> How can I help to identify if this is the root cause ? 

I'm not familar with Wayland implementation details.

The said memory must be allocated by one of the modules inside mesa/src/gallium/winsys/sw , but I'm not entirely sure which.

IF you breakpoint llvmpipe_displaytarget_layout() and step through, you should be eable to see how this memory is being created.

And you could then add some printfs or breakpoints to the deallocation.


Another thing you could do is to do `cat /proc/PID/smaps` and see if / what sort of memory range the memory falls into.


> if I build mesa with
> address sanitizer ,can I force mesa not to use jit to let address sanitizer
> to find if this is a heap-use-after-free ?

If this is device memory, I doubt that sort of tools works.  You could try valgrind.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/238.