Found by code inspection as of Mesa b2d5757831e2b67d87d3f80caa7f4ec10fce142b.

During compilation and linking, the functions glsl_type::get_array_instance(), glsl_type::get_record_instance(), and glsl_type::get_interface_instance() consult the hashtables array_types, record_types, and interface_types, which are statically declared in glsl_type (and hence are shared by all compilation units in all contexts).

There is no mechanism to ensure that these accesses to static data are thread-safe.  This means that if a client program tries to compile or link shaders concurrently from multiple threads, it may crash or get unpredictable results, even if the program takes appropriate thread safety measures (i.e. ensures that each context is in use by no more than one thread at a time).

This also means that if we ever want to give Mesa the ability to perform shader compilation in background threads, we will risk crashes or unpredictable results even when the client program is single-threaded.

I have three ideas about how to fix this problem:

1. Make the hashtables context local.  This would be pretty easy to implement and have negligible performance impact, but it would stop working if we ever tried to do shader compilation in background threads.

2. Guard access to the hashtables using mutexes.  This would be pretty easy to implement and would work if we ever tried to do shader compilation in background threads, but it might show down shader compilation.

3. Make the hashtables shader local.  This would be more difficult to implement, since it would mean that types could no longer be compared across shaders using pointer equality.  But it would address all thread safety issues and would probably have negligible performance impact.