cmake: 3.22 crashes under clang32 #10152

lazka · 2021-11-21T18:15:43Z

building libjpeg-turbo with newer cmake crashes. downgrading to 3.21.4 fixes things:

Thread 1 received signal SIGSEGV, Segmentation fault.
0x010eea42 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__set_short_size (this=0x10, __s=4) at C:/msys64/clang32/include/c++/v1/string:1500
1500            {__r_.first().__s.__size_ = (unsigned char)(__s << 1);}
(gdb) bt
#0  0x010eea42 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__set_short_size (this=0x10, __s=4)
    at C:/msys64/clang32/include/c++/v1/string:1500
#1  std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__init (this=0x10, __s=0x93e9d0 "@▒D\v@▒D\v\b▒", __sz=4)
    at C:/msys64/clang32/include/c++/v1/string:1882
#2  std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string (this=0x10, __s=0x93e9d0 "@▒D\v@▒D\v\b▒", __n=4)
    at C:/msys64/clang32/include/c++/v1/string:1915
#3  cmTimestamp::AddTimestampComponent (this=0x93ec18, flag=89 'Y',
    timeStruct=..., timeT=1637518452)
    at /usr/src/debug/cmake-3.22.0/Source/cmTimestamp.cxx:217
#4  0x010ee6bf in cmTimestamp::CreateTimestampFromTimeT (this=0x93ec18,
    timeT=<optimized out>, formatString=..., utcFlag=<optimized out>)
    at /usr/src/debug/cmake-3.22.0/Source/cmTimestamp.cxx:98
#5  0x010ee3b4 in cmTimestamp::CurrentTime (this=0x93ec18, formatString=...,
    utcFlag=<optimized out>)
    at /usr/src/debug/cmake-3.22.0/Source/cmTimestamp.cxx:46
#6  0x0108adbf in (anonymous namespace)::HandleTimestampCommand (args=...,
    status=...) at /usr/src/debug/cmake-3.22.0/Source/cmStringCommand.cxx:850
#7  0x0119c6ff in cmSubcommandTable::operator() (this=<optimized out>,
    key=..., args=..., status=...)
    at /usr/src/debug/cmake-3.22.0/Source/cmSubcommandTable.cxx:27
#8  0x0b458439 in ?? ()
Backtrace stopped: previous

https://gitlab.kitware.com/cmake/cmake/-/blob/55d0c88309c1fab0882b846085cdd5ddc6d9a105/Source/cmTimestamp.cxx#L217

The text was updated successfully, but these errors were encountered:

lazka · 2021-11-21T18:18:27Z

Minimal reproducer:

CMakeLists.txt:

string(TIMESTAMP DEFAULT_BUILD "%Y%m%d")

$ cmake .
-- Building for: Ninja
CMake Warning (dev) in CMakeLists.txt:
  No project() command is present.  The top-level CMakeLists.txt file must
  contain a literal, direct call to the project() command.  Add a line of
  code such as

    project(ProjectName)

  near the top of the file, but after cmake_minimum_required().

  CMake is pretending there is a "project(Project)" command on the first
  line.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- The C compiler identification is Clang 13.0.0
-- The CXX compiler identification is Clang 13.0.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/msys64/clang32/bin/cc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/msys64/clang32/bin/c++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX comp
Segmentation fault

lazka · 2021-11-21T18:24:27Z

Filed upstream: https://gitlab.kitware.com/cmake/cmake/-/issues/22939

lazka · 2021-11-21T19:03:02Z

workaround in #10153, but not sure why it crashes

Biswa96 · 2021-11-21T19:17:07Z

How is mingw-w64 related to this issue? The patch mentioned it to be reported to mingw-w64.

jeremyd2019 · 2021-11-21T20:54:55Z

workaround in #10153, but not sure why it crashes

Maybe 32 vs 64-bit time_t variants? Loading it by GetProcAddress wouldn't get the header logic to get the correct variant.

jeremyd2019 · 2021-11-22T06:02:33Z

workaround in #10153, but not sure why it crashes

Maybe 32 vs 64-bit time_t variants? Loading it by GetProcAddress wouldn't get the header logic to get the correct variant.

Nope, strftime uses struct tm not time_t. It looks like they're using a WINAPI (aka stdcall) function pointer for a cdecl function though, that could crash on 32-bit.

lazka · 2021-11-22T08:18:18Z

Interesting, git4windows also uses WINAPI for the same thing.. but could be it.

kanje · 2021-11-22T16:19:06Z

Yes, git4windows uses the same approach. Probably also because of this MINGW issue.

lazka · 2021-11-25T19:32:10Z

Filed PR for cmake: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6762

Filed issue for git4windows: git-for-windows/git#3560

Christoph Reiter reported on the Git for Windows issue tracker[1], that mingw_strftime() imports strftime() from ucrtbase.dll with the wrong calling convention. It should be __cdecl instead of WINAPI, which we always use in DECLARE_PROC_ADDR(). The MSYS2 project encountered cmake sefaults on x86 Windows caused by the same issue in the cmake source. [2] There are no known git crashes that where caused by this, yet, but we should try to prevent them. We import two other non-WINAPI functions via DECLARE_PROC_ADDR(), too. * NtSetSystemInformation() (NTAPI) * GetUserNameExW() (SEC_ENTRY) NTAPI, SEC_ENTRY and WINAPI are all ususally defined as __stdcall, but there are circumstances where they're defined differently. Teach DECLARE_PROC_ADDR() about calling conventions and be explicit about when we want to use which calling convention. Import winnt.h for the definition of NTAPI and security.h for SEC_ENTRY near their respective only users. [1] git-for-windows#3560 [2] msys2/MINGW-packages#10152 Reported-By: Christoph Reiter <reiter.christoph@gmail.com> Signed-off-by: Matthias Aßhauer <mha1993@live.de>

Christoph Reiter reported on the Git for Windows issue tracker[1], that mingw_strftime() imports strftime() from ucrtbase.dll with the wrong calling convention. It should be __cdecl instead of WINAPI, which we always use in DECLARE_PROC_ADDR(). The MSYS2 project encountered cmake sefaults on x86 Windows caused by the same issue in the cmake source. [2] There are no known git crashes that where caused by this, yet, but we should try to prevent them. We import two other non-WINAPI functions via DECLARE_PROC_ADDR(), too. * NtSetSystemInformation() (NTAPI) * GetUserNameExW() (SEC_ENTRY) NTAPI, SEC_ENTRY and WINAPI are all ususally defined as __stdcall, but there are circumstances where they're defined differently. Teach DECLARE_PROC_ADDR() about calling conventions and be explicit about when we want to use which calling convention. Import winnt.h for the definition of NTAPI and sspi.h for SEC_ENTRY near their respective only users. [1] git-for-windows#3560 [2] msys2/MINGW-packages#10152 Reported-By: Christoph Reiter <reiter.christoph@gmail.com> Signed-off-by: Matthias Aßhauer <mha1993@live.de>

Christoph Reiter reported on the Git for Windows issue tracker[1], that mingw_strftime() imports strftime() from ucrtbase.dll with the wrong calling convention. It should be __cdecl instead of WINAPI, which we always use in DECLARE_PROC_ADDR(). The MSYS2 project encountered cmake sefaults on x86 Windows caused by the same issue in the cmake source. [2] There are no known git crashes that where caused by this, yet, but we should try to prevent them. We import two other non-WINAPI functions via DECLARE_PROC_ADDR(), too. * NtSetSystemInformation() (NTAPI) * GetUserNameExW() (SEC_ENTRY) NTAPI, SEC_ENTRY and WINAPI are all ususally defined as __stdcall, but there are circumstances where they're defined differently. Teach DECLARE_PROC_ADDR() about calling conventions and be explicit about when we want to use which calling convention. Import winnt.h for the definition of NTAPI and sspi.h for SEC_ENTRY near their respective only users. [1] git-for-windows#3560 [2] msys2/MINGW-packages#10152 Reported-By: Christoph Reiter <reiter.christoph@gmail.com> Signed-off-by: Matthias Aßhauer <mha1993@live.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Christoph Reiter reported on the Git for Windows issue tracker[1], that mingw_strftime() imports strftime() from ucrtbase.dll with the wrong calling convention. It should be __cdecl instead of WINAPI, which we always use in DECLARE_PROC_ADDR(). The MSYS2 project encountered cmake sefaults on x86 Windows caused by the same issue in the cmake source. [2] There are no known git crashes that where caused by this, yet, but we should try to prevent them. We import two other non-WINAPI functions via DECLARE_PROC_ADDR(), too. * NtSetSystemInformation() (NTAPI) * GetUserNameExW() (SEC_ENTRY) NTAPI, SEC_ENTRY and WINAPI are all ususally defined as __stdcall, but there are circumstances where they're defined differently. Teach DECLARE_PROC_ADDR() about calling conventions and be explicit about when we want to use which calling convention. Import winnt.h for the definition of NTAPI and sspi.h for SEC_ENTRY near their respective only users. [1] #3560 [2] msys2/MINGW-packages#10152 Reported-By: Christoph Reiter <reiter.christoph@gmail.com> Signed-off-by: Matthias Aßhauer <mha1993@live.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>

lazka mentioned this issue Nov 21, 2021

libjpeg-turbo: update to 2.1.2 #10142

Merged

lazka mentioned this issue Nov 21, 2021

cmake: work around crash #10153

Merged

lazka changed the title ~~cmake 3.22 crashes under clang32~~ cmake: 3.22 crashes under clang32 Nov 21, 2021

lazka mentioned this issue Nov 25, 2021

mingw_strftime: wrong calling convention git-for-windows/git#3560

Closed

lazka closed this as completed Nov 25, 2021

rimrul mentioned this issue Jan 8, 2022

lazyload: use correct calling conventions git/git#1181

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmake: 3.22 crashes under clang32 #10152

cmake: 3.22 crashes under clang32 #10152

lazka commented Nov 21, 2021 •

edited

Loading

lazka commented Nov 21, 2021 •

edited

Loading

lazka commented Nov 21, 2021

lazka commented Nov 21, 2021

Biswa96 commented Nov 21, 2021

jeremyd2019 commented Nov 21, 2021 •

edited

Loading

jeremyd2019 commented Nov 22, 2021 •

edited

Loading

lazka commented Nov 22, 2021

kanje commented Nov 22, 2021

lazka commented Nov 25, 2021 •

edited

Loading

cmake: 3.22 crashes under clang32 #10152

cmake: 3.22 crashes under clang32 #10152

Comments

lazka commented Nov 21, 2021 • edited Loading

lazka commented Nov 21, 2021 • edited Loading

lazka commented Nov 21, 2021

lazka commented Nov 21, 2021

Biswa96 commented Nov 21, 2021

jeremyd2019 commented Nov 21, 2021 • edited Loading

jeremyd2019 commented Nov 22, 2021 • edited Loading

lazka commented Nov 22, 2021

kanje commented Nov 22, 2021

lazka commented Nov 25, 2021 • edited Loading

lazka commented Nov 21, 2021 •

edited

Loading

lazka commented Nov 21, 2021 •

edited

Loading

jeremyd2019 commented Nov 21, 2021 •

edited

Loading

jeremyd2019 commented Nov 22, 2021 •

edited

Loading

lazka commented Nov 25, 2021 •

edited

Loading