Segfault on Archlinux

[kemazode]

The game freezes a second after the appearance of the main screen and crashes.

$ gdb openspades
gdb.txt
Last two lines:

Thread 1 "openspades" received signal SIGSEGV, Segmentation fault.
0x00005555557135c0 in spades::RefCountedObject::AddRef() ()

$ valgrind --leak-check=full --show-leak-kinds=all openspades
valgrind.txt

[NotAFile]

what revision is this on?

[kemazode]

openspades 0.1.3-1 from aur

[yvt]

Thanks for the report! Can you provide the backtrace (if possible)?

[kemazode]

(gdb) set logging file gdbtrace.log
(gdb) set logging on
(gdb) run --no-daemon --verbose
(gdb) thread apply all bt full
(gdb) set logging off
(gdb) quit
gdbtrace.txt

strace openspades:
strace.txt

maybe it's not quite right, but there is definitely something
("Нет такого файла или каталога" -> "No such file or directory")

[yvt]

@yachmenka Thanks, that'll give us a clearer insight into the problem.

The segfault seems to have occurred in the sorting routine (std::stable_sort) because the use of std::_Temporary_buffer (Listing 1) is characteristic to the standard library's sorting routines. Listing 2 shows that RefCountedObject::Release was called during the function call, which is completely unexpected because the sorting routine is supposed to only exchange elements, not to destroy any of them. Finally, Release caused the segfault probably because of an invalid this pointer, suggesting the temporary buffer was corrupt at the point of the function call. This also explains the unexpected call to Release.

Listing 1:

==9470==    at 0x3A6C1F: std::_Temporary_buffer<__gnu_cxx::__normal_iterator<spades::Handle<spades::gui::MainScreenServerItem>*, std::vector<spades::Handle<spades::gui::MainScreenServerItem>, std::allocator<spades::Handle<spades::gui::MainScreenServerItem> > > >, spades::Handle<spades::gui::MainScreenServerItem> >::_Temporary_buffer(__gnu_cxx::__normal_iterator<spades::Handle<spades::gui::MainScreenServerItem>*, std::vector<spades::Handle<spades::gui::MainScreenServerItem>, std::allocator<spades::Handle<spades::gui::MainScreenServerItem> > > >, long) (in /usr/bin/openspades)
==9470==    by 0x3A55C1: spades::gui::MainScreenHelper::GetServerList(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool) (in /usr/bin/openspades)
==9470==    by 0x475257: ??? (in /usr/bin/openspades)

Listing 2:

Thread 1 (Thread 0x7ffff5a54780 (LWP 10148)):
#0  0x00005555557135d5 in spades::RefCountedObject::Release() ()
No symbol table info available.
#1  0x00005555557e355c in ?? ()
No symbol table info available.
#2  0x00005555557e49e8 in ?? ()
No symbol table info available.
#3  0x00005555557ef2c2 in ?? ()
No symbol table info available.
#4  0x00005555557f15e9 in spades::gui::MainScreenHelper::GetServerList(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool) ()

I have no plausible explanation for the memory corruption at the moment, I'm afraid.

p.s. If you need a quick work-around, change cl_serverListUrl to something else to disable the integrated server list.

[kemazode]

Yeah, thx

[samuelallan72]

I've been doing some debugging because this has affected me too:

• reproducible on openspades-git on aur (this builds git master)
• I can't reproduce by building manually from the instructions in the readme (cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo && make)
• I can reproduce by building with -D CMAKE_BUILD_TYPE=Release as in the aur package.

Perhaps the Release build type is invalid/bugged now? Do we have a list of allowed build types? (I'm unfamiliar with cmake.)

@yachmenka if you change the CMAKE_BUILD_TYPE to RelWithDebInfo in the pkgbuild does it resolve the segfault?

[NotAFile]

I wonder, does this change if you change the cmake generator?

say, adding the cmake -G Ninja option

[samuelallan72]

@NotAFile interesting! Building with the following doesn't result in the above segfault:

mkdir openspades.mk
cd openspades.mk
cmake -G Ninja ..
ninja
./bin/openspades

Definitely appears to be something odd happening from cmake then?

[NotAFile]

Sounds like a bug in cmake's make generator, yeah.

[mschlumpp]

@swalladge The command sequence you posted doesn't use the Release configuration. Try "cmake -DCMAKE_BUILD_TYPE=Release -GNinja .." instead.

The main difference between RelWithDebInfo and Release is that Release uses -O3 instead of -O2. The more aggressive optimization level could trigger some undefined behaviour somewhere. Possibly in the OS or libstdc++ codebase. At least some older libstdc++ version seemed to have a bug in std::sort.

[samuelallan72]

@theunknownxy Ah yeah true. It segfaults the same with Release build type and ninja... I think you're right about the optimisation level being the issue.