Anonymous Login
2019-07-24 01:10 UTC

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001661OpenClonkEnginepublic2016-02-08 02:07
ReporterLuchs 
Assigned ToIsilkor 
PrioritynormalSeveritycrashReproducibilityalways
StatusresolvedResolutionfixed 
PlatformClangOSLinuxOS Version
Product Version 
Target VersionFixed in Version 
Summary0001661: Builds by Clang with optimizations enabled don't work properly
Description - Builds with optimizations disabled (-O0) work fine.

 - Builds with -O1 work fine, but text colors are weird (see attached screenshot).

 - Builds with -O2 and -O3 segfault on start. Backtrace is attached below. This seems to be an issue with GNU libstdc++, not sure whether OC can fix anything there.
Additional Information[20:34:45] OpenClonk
[20:34:45] Version: 8.0-alpha unix linux-x86_64 (6e251832b87e)
[20:34:45] ExePath: "/home/lukas/src/openclonk/build/"
[20:34:45] SystemDataPath: "/usr/local/share/games/openclonk/"
[20:34:45] UserDataPath: "/home/lukas/.clonk/openclonk/"
[20:34:45] Command line: /home/lukas/src/openclonk/build/openclonk-clang-o2

Program received signal SIGSEGV, Segmentation fault.
std::__cxx11::sub_match<char const*>::str (this=0xffffffffffffffb8)
    at /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/bits/regex.h:867
867 return this->matched
(gdb) bt
#0 std::__cxx11::sub_match<char const*>::str (this=0xffffffffffffffb8)
    at /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/bits/regex.h:867
#1 0x0000000000541156 in std::__cxx11::sub_match<char const*>::compare (this=<optimized out>, __s=...)
    at /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/bits/regex.h:883
#2 0x000000000052df52 in std::__cxx11::operator==<char const*> (__lhs=..., __rhs=...)
    at /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/bits/regex.h:938
0000003 std::__cxx11::regex_iterator<char const*, char, std::__cxx11::regex_traits<char> >::operator== (this=<optimized out>, __rhs=...)
    at /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/bits/regex.tcc:517
#4 std::__cxx11::regex_iterator<char const*, char, std::__cxx11::regex_traits<char> >::operator!= (this=<optimized out>, __rhs=...)
    at /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/bits/regex.h:2497
0000005 (anonymous namespace)::GetResStr[abi:cxx11](char const*, char const*) (id=<optimized out>, stringtbl=<optimized out>)
    at ../src/c4group/C4Language.cpp:272
0000006 (anonymous namespace)::CopyResStr<1025ul> (id=0x7e6416 "IDS_LANG_NAME", stringtbl=<optimized out>, dest=...)
    at ../src/c4group/C4Language.cpp:294
0000007 0x000000000052dd37 in C4Language::LoadInfos (this=<optimized out>, hGroup=...) at ../src/c4group/C4Language.cpp:320
0000008 0x000000000052d5be in C4Language::InitInfos (this=0xb7a1f0 <Languages>) at ../src/c4group/C4Language.cpp:238
0000009 0x000000000052d517 in C4Language::Init (this=0xb7a1f0 <Languages>) at ../src/c4group/C4Language.cpp:100
#10 0x000000000058c202 in C4Application::DoInit (this=0xb333c8 <Application>, argc=<optimized out>, argv=<optimized out>)
    at ../src/game/C4Application.cpp:141
0000011 0x00000000005294a5 in C4AbstractApp::Init (this=0xb333c8 <Application>, argc=<optimized out>, argv=<optimized out>)
    at ../src/platform/C4AppGTK.cpp:85
#12 0x0000000000520e56 in main (argc=1, argv=0x7fffffffe1a8) at ../src/game/ClonkMain.cpp:231
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0004926

Luchs (administrator)

Builds with libc++ (instead of libstdc++) and -O2 don't segfault, but still have the font color issue.

~0004929

Luchs (administrator)

By selectively disabling optimizations (#pragma clang optimize off), I was able to find the broken function. Text color works fine when disabling optimization on the function BltAlpha() in lib/StdColors.h [1] only. There seems to be some issue with the casts to signed integers there. When those casts are removed, the text color issue disappears as well.

Maybe someone with more knowledge about these functions can reconsider those casts to signed integers?

[1]: https://github.com/openclonk/openclonk/blob/a390f8f2482c8dd1ebec4d90dd529611a87bdcb2/src/lib/StdColors.h#L33-L42

~0004931

Sven2 (developer)

Removing the int casts from this function looks fine to me.

Also, BltAlphaAdd, LightenClrBy and DarkenClrBy may need to be adjusted.

~0004951

Isilkor (developer)

I bet clang assumes that the multiplication in [1], [2] can't overflow, because that's undefined. I have no idea why those casts to int are there; the only thing they do is break stuff. The other functions are fine because there we actually want to allow the variable to become negative; we clamp it to 0..255 later anyway. Actually, ModulateClrMOD2 might be broken too, not because of an overflow but because the clamp bounds seem wrong.

[1] https://github.com/openclonk/openclonk/blob/a390f8f2482c8dd1ebec4d90dd529611a87bdcb2/src/lib/StdColors.h#L40
[2] https://github.com/openclonk/openclonk/blob/a390f8f2482c8dd1ebec4d90dd529611a87bdcb2/src/lib/StdColors.h#L51

~0004952

occ (reporter)

Hi! There's been a check-in that references this bug. For more information you can visit the repository browser at this address:
https://git.openclonk.org/openclonk.git/commitdiff/5fe327663f731337022ef0528ec12a9bc25d8392

Changeset 5fe3276 by Nicolas Hake <isilkor@openclonk.org>
Fix signed int overflow in BltAlpha (0001661)

The red color channel calculation could overflow into the sign bit,
which is undefined behavior. At least one compiler takes advantage of
this and assumes it cannot happen, resulting in incorrect results.

BltAlphaAdd looks similar, but does in fact not have this bug because it
shifts the color channel far enough that multiplication can't overflow.

~0004953

Isilkor (developer)

I've also looked over the nullpointer deref in std::regex_iterator that you had happen with clang and libstdc++, and the code seems legit to me. I'm going to chalk that up to some strange compiler and/or library bug, because it shouldn't do submatch comparisons when checking an iterator against the end-of-sequence iterator. Marking this fixed for the int overflow though.
+Notes

-Issue History
Date Modified Username Field Change
2016-01-31 19:56 Luchs New Issue
2016-01-31 20:11 Luchs Note Added: 0004926
2016-02-01 17:04 Luchs Note Added: 0004929
2016-02-01 22:58 Sven2 Note Added: 0004931
2016-02-08 01:33 Isilkor Note Added: 0004951
2016-02-08 02:04 occ Note Added: 0004952
2016-02-08 02:07 Isilkor Note Added: 0004953
2016-02-08 02:07 Isilkor Status new => resolved
2016-02-08 02:07 Isilkor Resolution open => fixed
2016-02-08 02:07 Isilkor Assigned To => Isilkor
+Issue History