<div dir="ltr">Seeing the source code in disassembly and the stacktrace, it appears to me that the problem is in the std:: basic_string(), not related to mesa-dev. Although, it's strange to me the source of this include is at MSVC dir (according to VS2017) and opengl32.dll was compiled using LLVM. Maybe the problem is LLVM compilation, not the mesa-dev compilation.<div> Disassembly with source: 1922: basic_string(const basic_string& _Right) 1923: : _Mybase(_Alty_traits::select_on_container_copy_construction(_Right._Getal())) 00007FF85FBF874B 48 89 41 18 mov qword ptr [rcx+18h],rax 1925: _Construct_lv_contents(_Right); 00007FF85FBF874F 48 83 7A 18 10 cmp qword ptr [rdx+18h],10h 00007FF85FBF8754 48 8B 6A 10 mov rbp,qword ptr [rdx+10h] 00007FF85FBF8758 72 03 jb std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string<char,std::char_traits<char>,std::allocator<char> >+2Dh (07FF85FBF875Dh) 00007FF85FBF875A 48 8B 32 mov rsi,qword ptr [rdx] 00007FF85FBF875D 48 83 FD 10 cmp rbp,10h 00007FF85FBF8761 73 27 jae std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string<char,std::char_traits<char>,std::allocator<char> >+5Ah (07FF85FBF878Ah) 00007FF85FBF8763 C5 F8 10 06 vmovups xmm0,xmmword ptr [rsi] 00007FF85FBF8767 C5 F8 11 01 vmovups xmmword ptr [rcx],xmm0 00007FF85FBF876B 48 89 69 10 mov qword ptr [rcx+10h],rbp Include path of source in disassembly: c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\xstring Stacktrace: > opengl32.dll!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string<char,std::char_traits<char>,std::allocator<char> >(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & _Right) Line 1925 C++ Symbols loaded. [External Code] Annotated Frame opengl32.dll!_initterm(void(*)() * first, void(*)() * last) Line 16 C++ Symbols loaded. [External Code] Annotated Frame python36.dll!000000005e137fd8() Unknown No symbols loaded. python36.dll!000000005e1376ca() Unknown No symbols loaded. python36.dll!000000005e1372a1() Unknown No symbols loaded. python36.dll!000000005e137217() Unknown No symbols loaded.</div></div><div class="gmail_extra"> <div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><table width="230" border="0" style="color:rgb(33,33,33);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px"><tbody><tr><td width="82" height="80" align="left"><a title="MiningMath Associates" href="http://www.miningmath.com/component/content/article/4.html?src=ass&mdm=email&cpn=FAC#Fabrício+Ceolin" style="color:rgb(126,87,194);outline:transparent solid 1px" target="_blank"><img width="82" height="80" border="0" alt="MiningMath Associates" src="http://www.miningmath.com/divulgacao/elogo.png"></a></td><td width="148" height="80" align="center">Fabrício Ceolin <a title="tel:+55 (31) 8675-1359" style="color:rgb(51,103,214)">+55 (31) 98675-1359</a> <a title="MiningMath Associates" href="http://www.miningmath.com/?src=ass&mdm=email&cpn=FAC" style="color:rgb(126,87,194)" target="_blank">MiningMath Associates</a> <a title="www.miningmath.com" href="http://www.miningmath.com/?src=ass&mdm=email&cpn=FAC" style="color:rgb(126,87,194)" target="_blank">www.miningmath.com</a> </td></tr></tbody></table></div><div> </div></div></div></div> <div class="gmail_quote">2017-10-25 20:55 GMT-02:00 Roland Scheidegger <<a href="mailto:sroland@vmware.com" target="_blank">sroland@vmware.com</a>>: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 26.10.2017 um 00:26 schrieb Ilia Mirkin: > On Wed, Oct 25, 2017 at 6:15 PM, Fabrício Ceolin > <<a href="mailto:fabricio.ceolin@miningmath.com">fabricio.ceolin@miningmath.com</a> <mailto:<a href="mailto:fabricio.ceolin@miningmath.com">fabricio.ceolin@miningmath.com</a>>> <div><div class="h5">> wrote: > > Hi, > > Thanks. I recompiled everything (on Windows) using this real machine: > > #under msys2 > $ cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 23 > model name : Genuine Intel(R) CPU U2300 @ 1.20GHz > stepping : 10 > cpu MHz : 1197.000 > cache size : 1024 KB > physical id : 0 > siblings : 2 > core id : 0 > cpu cores : 2 > apicid : 0 > initial apicid : 0 > fpu : yes > fpu_exception : yes > cpuid level : 13 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr > pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm > pbe pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm xsave > osxsave lahf_lm dtherm > clflush size : 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: > > but I got the same error: > > 00007FF85FBF874F 48 83 7A 18 10 cmp qword ptr > [rdx+18h],10h > 00007FF85FBF8754 48 8B 6A 10 mov rbp,qword ptr > [rdx+10h] > 00007FF85FBF8758 72 03 jb > std::basic_string<char,std::char_traits<char>,std::allocator<char> > >::basic_string<char,std::char_traits<char>,std::allocator<char> > >+2Dh (07FF85FBF875Dh) > 00007FF85FBF875A 48 8B 32 mov rsi,qword ptr [rdx] > 00007FF85FBF875D 48 83 FD 10 cmp rbp,10h > 00007FF85FBF8761 73 27 jae > std::basic_string<char,std::char_traits<char>,std::allocator<char> > >::basic_string<char,std::char_traits<char>,std::allocator<char> > >+5Ah (07FF85FBF878Ah) </div></div>> *00007FF85FBF8763 C5 F8 10 06 vmovups xmm0,xmmword ptr > [rsi] * > 00007FF85FBF8767 C5 F8 11 01 vmovups xmmword ptr > [rcx],xmm0 > 00007FF85FBF876B 48 89 69 10 mov qword ptr > [rcx+10h],rbp > > Are there any parameters that I can use for avoid to use AVX (or > better) instructions? > > > LP_NATIVE_VECTOR_WIDTH=128 should force you to a non-avx path. There's > also a LP_FORCE_SSE2=1 which will also avoid sse3/4 usage. However all > this stuff should be getting detected, so it's odd that it's messing up. > Perhaps run with GALLIUM_DUMP_CPU=1 to see what's being detected? > Also, a backtrace when it crashes would be nice. I am not convinced this is actually happening inside a code-generated shader... Roland </blockquote></div> </div>