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. 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. [image: MiningMath Associates] <http://www.miningmath.com/component/content/article/4.html?src=ass&mdm=email&cpn=FAC#Fabrício+Ceolin> *Fabrício Ceolin* +55 (31) 98675-1359 MiningMath Associates <http://www.miningmath.com/?src=ass&mdm=email&cpn=FAC> www.miningmath.com <http://www.miningmath.com/?src=ass&mdm=email&cpn=FAC> 2017-10-25 20:55 GMT-02:00 Roland Scheidegger <srol...@vmware.com>: > Am 26.10.2017 um 00:26 schrieb Ilia Mirkin: > > On Wed, Oct 25, 2017 at 6:15 PM, Fabrício Ceolin > > <fabricio.ceo...@miningmath.com <mailto:fabricio.ceo...@miningmath.com>> > > 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) > > *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 > > >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
