Crash when using with Mesa under Linux

[GoogleCodeExporter]

Using TSAN included in g++ 4.9 I get a perfectly reproducible crash as soon as 
the code calls glClear():

Program received signal SIGSEGV, Segmentation fault.
__tsan::MemoryAccessRange (thr=0x80, pc=pc@entry=140514723803966, addr=0, 
size=128, is_write=is_write@entry=true) at 
../../../../src/libsanitizer/tsan/tsan_rtl_thread.cc:348
348     ../../../../src/libsanitizer/tsan/tsan_rtl_thread.cc: No such file or 
directory.
(gdb) bt 12
#0  __tsan::MemoryAccessRange (thr=0x80, pc=pc@entry=140514723803966, addr=0, 
size=128, is_write=is_write@entry=true) at 
../../../../src/libsanitizer/tsan/tsan_rtl_thread.cc:348
#1  0x00007fcc2232b3ac in __interceptor_memcpy (dst=0x0, 
src=src@entry=0x7d8000015000, size=size@entry=128) at 
../../../../src/libsanitizer/tsan/tsan_interceptors.cc:628
#2  0x00007fcbe74351d4 in memcpy (__len=128, __src=0x7d8000015000, 
__dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string3.h:51
#3  brw_upload_constant_buffer (brw=0x7fcbe61de028) at 
../../../../../../../src/mesa/drivers/dri/i965/brw_curbe.c:293
#4  0x00007fcbe74884ca in brw_upload_state (brw=brw@entry=0x7fcbe61de028) at 
../../../../../../../src/mesa/drivers/dri/i965/brw_state_upload.c:645
#5  0x00007fcbe7438c77 in brw_try_draw_prims (indirect=<optimized out>, 
max_index=<optimized out>, min_index=<optimized out>, ib=<optimized out>, 
nr_prims=<optimized out>, 
    prims=<optimized out>, arrays=<optimized out>, ctx=0x7fcbe61de028) at ../../../../../../../src/mesa/drivers/dri/i965/brw_draw.c:475
#6  brw_draw_prims (ctx=0x7fcbe61de028, prims=<optimized out>, 
nr_prims=<optimized out>, ib=<optimized out>, index_bounds_valid=<optimized 
out>, min_index=0, max_index=3, 
    unused_tfb_object=0x0, indirect=0x0) at ../../../../../../../src/mesa/drivers/dri/i965/brw_draw.c:569
#7  0x00007fcbe7296a4d in vbo_draw_arrays (ctx=0x7fcbe61de028, 
mode=mode@entry=6, start=start@entry=0, count=count@entry=4, 
numInstances=numInstances@entry=1, 
    baseInstance=baseInstance@entry=0) at ../../../../src/mesa/vbo/vbo_exec_array.c:661
#8  0x00007fcbe7296bf3 in vbo_exec_DrawArrays (mode=mode@entry=6, 
start=start@entry=0, count=count@entry=4) at 
../../../../src/mesa/vbo/vbo_exec_array.c:813
#9  0x00007fcbe72980e5 in _mesa_DrawArrays (mode=mode@entry=6, 
first=first@entry=0, count=count@entry=4) at 
../../../../src/mesa/vbo/vbo_exec_array.c:1882
#10 0x00007fcbe7324631 in _mesa_meta_glsl_Clear (ctx=ctx@entry=0x7fcbe61de028, 
buffers=buffers@entry=2) at ../../../../src/mesa/drivers/common/meta.c:2430
#11 0x00007fcbe74294db in brw_clear (ctx=0x7fcbe61de028, mask=0) at 
../../../../../../../src/mesa/drivers/dri/i965/brw_clear.c:261
#12 0x00007fc23bce1903 in my code at the line calling glClear()

Please let me know if I can provide any additional information.

Original issue reported on code.google.com by vzeitlin@gmail.com on 26 Apr 2014 at 11:38

[GoogleCodeExporter]

This line suggests that the program tries to copy something to NULL address:
__interceptor_memcpy (dst=0x0, src=src@entry=0x7d8000015000, 
size=size@entry=128)
which is expected to crash.

Please double check that the program itself is not buggy.
If you run it with -fsanitize=address, what is the output?

Original comment by dvyu...@google.com on 26 Apr 2014 at 11:47

[GoogleCodeExporter]

I've been running it under address sanitizer for quite some time and there are 
no errors (unfortunately, I do believe there is a bug in the program somewhere 
as it sporadically results in glMapBuffer() failure -- but it happens very 
rarely and I couldn't pinpoint it yet). Moreover, the line in the stack trace 
#12 is literally just

glClear(GL_COLOR_BUFFER_BIT);

Perhaps there is something wrong inside Mesa GL driver, but this is, 
unfortunately outside of my control, so I'd like to blacklist it if I could, 
but I don't see any way to prevent this crash from happening...

Original comment by vzeitlin@gmail.com on 26 Apr 2014 at 12:10

[GoogleCodeExporter]

ThreadSanitizer can significantly disturb timings and cause the bug to happen 
much more frequently.
I can suggest to nsert printf before the memcpy call, to verify NULL 
hypothesis. If it's just a bug in mesa, then there is not much we can do.
You can also try with clang tip instead of gcc (here are build instructions 
https://code.google.com/p/address-sanitizer/wiki/HowToBuild) maybe it will 
affect something (or maybe a clang compilation warning will point you to the 
bug).

Original comment by dvyu...@google.com on 26 Apr 2014 at 12:22

[GoogleCodeExporter]

Just to be clear: with TSAN, it's not a timing problem, the crash happens 
immediately on startup, i.e. on the very first call to glClear().

I might try it with clang later but for now I managed to finally get something 
from valgrind so I'm going to investigate this first...

Original comment by vzeitlin@gmail.com on 26 Apr 2014 at 12:50

[GoogleCodeExporter]

I will appreciate if you report back with your findings. If it's a bug in tsan, 
I would like to fix it.

Original comment by dvyu...@google.com on 27 Apr 2014 at 10:08

[GoogleCodeExporter]

Closing, but you still can report your findings here.

Original comment by dvyu...@google.com on 7 May 2014 at 8:59

• Changed state: WontFix