<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Unreal Tournament (UT99) segfault on opengl init" href="https://bugs.freedesktop.org/show_bug.cgi?id=108933#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Unreal Tournament (UT99) segfault on opengl init" href="https://bugs.freedesktop.org/show_bug.cgi?id=108933">bug 108933</a> from <a class="email" href="mailto:iive@yahoo.com" title="iive@yahoo.com">iive@yahoo.com</a> <pre>I got the UT99 working. valgrind doesn't show anything more, the first error is the one from the report. When trying to narrow mesa releases that work, I got mesa-18.1.7 working and mesa-18.2.0 not working. However the bisect failed. Even compiling mesa-18.0.0 also produces broken compilation. Since I've done major update before compiling my mesa-18.2.0, it makes sense that the bug is gcc/glibc related. I had libstdc++.so.6.25 used, so I got an older libstdc++.so.6.24 one instead. The problem remained. (I'm sure it got used, because I forgot to fix the link and got another error.) I tried compiling with -O0, but the bug remains. It is not miscompilation, per se. It is more likely to be something related to ABI/API. Here is the backtrace of current Mesa 19.0.0-devel (git-3b2ad8b290) --- #1 0xf1be6ba8 in bool std::has_facet<std::ctype<char> >(std::locale const&) () from /usr/lib/libstdc++.so.6 #2 0xf1bd6f1a in std::basic_ios<char, std::char_traits<char> >::_M_cache_locale(std::locale const&) () from /usr/lib/libstdc++.so.6 #3 0xf1bd7399 in std::basic_ios<char, std::char_traits<char> >::init(std::basic_streambuf<char, std::char_traits<char> >*) () from /usr/lib/libstdc++.so.6 #4 0xf1b75563 in std::ios_base::Init::Init() () from /usr/lib/libstdc++.so.6 #5 0xf5485d4b in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /usr/include/c++/8.2.0/iostream:74 #6 0xf5485d93 in _GLOBAL__sub_I_st_glsl_to_tgsi_temprename.cpp(void) () at state_tracker/st_glsl_to_tgsi_temprename.cpp:1426 #7 0xf595cc82 in __do_global_ctors_aux () from /usr/lib/xorg/modules/dri/r600_dri.so #8 0xf2230dc0 in ?? () from /usr/lib/libLLVM-6.0.so #9 0xf514c025 in _init () from /usr/lib/xorg/modules/dri/r600_dri.so #10 0xf4df26bc in ?? () from /usr/lib/libLLVM-6.0.so --- The disassembly of the function in frame #1 looks like this: --- [...] 0xf1be6b99 <+73>: mov -0x2a8(%ebx),%eax 0xf1be6b9f <+79>: mov %eax,0x4(%esp) 0xf1be6ba3 <+83>: call 0xf1b5a570 <__dynamic_cast@plt> => 0xf1be6ba8 <+88>: test %eax,%eax 0xf1be6baa <+90>: setne %al 0xf1be6bad <+93>: add $0x18,%esp 0xf1be6bb0 <+96>: pop %ebx 0xf1be6bb1 <+97>: ret --- Frame #6 is the closing bracket of dump_instruction() debug function. Hollowing the whole function (#if/#endif) just moved the line number. I'm not that familiar with C++ and debugging it. Maybe somebody could weight in. It seems that on init something calls global constructors and one of them needs something that is not yet initialized or something.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>