Skip to content
This repository has been archived by the owner on Jun 25, 2020. It is now read-only.

Crash on Windows when running for instance juci . src/menu.cc src/menu.h #84

Closed
eidheim opened this issue Nov 7, 2015 · 26 comments
Closed

Crash on Windows when running for instance juci . src/menu.cc src/menu.h #84

eidheim opened this issue Nov 7, 2015 · 26 comments
Assignees
@eidheim
Labels
solved

Comments

@eidheim
Copy link
Member

eidheim commented Nov 7, 2015

I think the issue was introduced with a new clang version (3.7), will fix this Today or Tomorrow hopefully.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2476.0x3fc]
0x000000000378e664 in ?? () from c:\msys64\mingw64\bin\libclang.dll
(gdb) backtrace
#0  0x000000000378e664 in ?? () from c:\msys64\mingw64\bin\libclang.dll
#1  0x0000000002e6a236 in ?? () from c:\msys64\mingw64\bin\libclang.dll
#2  0x0000000002e6c0b7 in ?? () from c:\msys64\mingw64\bin\libclang.dll
#3  0x0000000002c89c28 in ?? () from c:\msys64\mingw64\bin\libclang.dll
#4  0x000000000378e986 in ?? () from c:\msys64\mingw64\bin\libclang.dll
#5  0x000000000378e9e7 in ?? () from c:\msys64\mingw64\bin\libclang.dll
#6  0x000000000378ea48 in ?? () from c:\msys64\mingw64\bin\libclang.dll
#7  0x0000000002c7a77a in ?? () from c:\msys64\mingw64\bin\libclang.dll
#8  0x0000000002c8b32e in ?? () from c:\msys64\mingw64\bin\libclang.dll
#9  0x0000000000472aa1 in clang::TranslationUnit::ReparseTranslationUnit (
    this=0x7c16ab0, Python Exception <type 'exceptions.ValueError'> Cannot find type const std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::_Rep_type:
buffers=std::map with 1 elements, flags=142)
    at C:/msys64/home/olece/jucipp/libclangmm/src/TranslationUnit.cc:70
#10 0x00000000004223f4 in Source::ClangViewParse::<lambda()>::operator() (
    __closure=0x7c1eb68)
    at C:/msys64/home/olece/jucipp/src/source_clang.cc:148
#11 std::_Bind_simple<Source::ClangViewParse::init_parse()::<lambda()>()>::_M_invoke<> (this=0x7c1eb68)
    at C:/msys64/mingw64/include/c++/5.2.0/functional:1531
#12 std::_Bind_simple<Source::ClangViewParse::init_parse()::<lambda()>()>::operator() (this=0x7c1eb68) at C:/msys64/mingw64/include/c++/5.2.0/functional:1520
#13 std::thread::_Impl<std::_Bind_simple<Source::ClangViewParse::init_parse()::<lambda()>()> >::_M_run(void) (this=0x7c1eb50)
    at C:/msys64/mingw64/include/c++/5.2.0/thread:115
#14 0x000000006fd06050 in ?? () from c:\msys64\mingw64\bin\libstdc++-6.dll
#15 0x0000000064944ac4 in ?? () from c:\msys64\mingw64\bin\libwinpthread-1.dll
#16 0x000007feffcb415f in srand () from C:\Windows\system32\msvcrt.dll
#17 0x000007feffcb6ebd in msvcrt!_ftime64_s ()
   from C:\Windows\system32\msvcrt.dll
#18 0x0000000077ab5a4d in KERNEL32!BaseThreadInitThunk ()
   from C:\Windows\system32\kernel32.dll
#19 0x0000000077beb831 in ntdll!RtlUserThreadStart ()
   from C:\Windows\SYSTEM32\ntdll.dll
#20 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
@eidheim
Copy link
Member Author

eidheim commented Nov 7, 2015

Have no clue whatsoever why it says Python Exception...

Edit: this is because gdb uses python I think

@eidheim eidheim self-assigned this Nov 7, 2015
@eidheim
Copy link
Member Author

eidheim commented Nov 7, 2015

Seems like libclang on MSYS2 is compiled without threads: https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-clang/PKGBUILD. This is most likely the issue.

@eidheim
Copy link
Member Author

eidheim commented Nov 7, 2015

Temporary fix is to add a mutex on the clang operations in jucipp if MSYS2, untill libclang or MSYS fixes the issue. I think its fixed in the lates libclang svn. I'll fix it

@eidheim
Copy link
Member Author

eidheim commented Nov 20, 2015

Have confirmed that setting -DLLVM_ENABLE_THREADS=1 at https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-clang/PKGBUILD#L194 fixes this issue.

I will make a pull request on this, but have to fix a sha256sum as well. Tomorrow or so.

@zalox
Copy link
Member

zalox commented Nov 21, 2015

That's great news! clang calls have been terrible on windows lately.

@eidheim
Copy link
Member Author

eidheim commented Nov 21, 2015

It might also be that we currently combine posix and windows threads on windows. Will try to only use windows threads tomorrow through boost threads instead.

@eidheim
Copy link
Member Author

eidheim commented Nov 22, 2015

The issue is LLVM_ENABLE_THREADS that cannot be 0. I'll create a pull request.

@eidheim
Copy link
Member Author

eidheim commented Nov 22, 2015

Created Alexpux/MINGW-packages#905

@zalox
Copy link
Member

zalox commented Nov 24, 2015

How do boost::threads compare to std::threads in unix? I guess it's cleaner to just use boost, even if that introduces longer compile time.

@eidheim
Copy link
Member Author

eidheim commented Nov 24, 2015

I was not sure what kind of threads the boost package used in MSYS2, but it was not the issue. I think we should use std:: if possible. std::thread for instance is probably now used more than boost::thread, and is thus more well tested on various platforms. boost::regex however, is probably used more than std::regex since it is not supported in gcc4.8, but in a year or so, we should move to std::regex:)

@eidheim eidheim added the solved label Dec 9, 2015
@eidheim
Copy link
Member Author

eidheim commented Dec 9, 2015

The PR in Alexpux/MINGW-packages have been merged, hopefully the new clang package will be built soon. Closing this issue then.

@eidheim
Copy link
Member Author

eidheim commented Dec 10, 2015

@mingwandroid sorry to bother you again, but just a quick question since there are no new clang package yet when I do pacman -Suy. Is this a problem:

$ makepkg-mingw -sLf
==> Making package: mingw-w64-clang 3.7.0-8 (Thu, Dec 10, 2015  4:14:14 PM)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found llvm-3.7.0.src.tar.xz
  -> Found llvm-3.7.0.src.tar.xz.sig
  -> Found cfe-3.7.0.src.tar.xz
  -> Found cfe-3.7.0.src.tar.xz.sig
  -> Found compiler-rt-3.7.0.src.tar.xz
  -> Found compiler-rt-3.7.0.src.tar.xz.sig
  -> Found test-suite-3.7.0.src.tar.xz
  -> Found test-suite-3.7.0.src.tar.xz.sig
  -> Found libcxx-3.7.0.src.tar.xz
  -> Found libcxx-3.7.0.src.tar.xz.sig
  -> Found libcxxabi-3.7.0.src.tar.xz
  -> Found libcxxabi-3.7.0.src.tar.xz.sig
  -> Found clang-tools-extra-3.7.0.src.tar.xz
  -> Found clang-tools-extra-3.7.0.src.tar.xz.sig
  -> Found lld-3.7.0.src.tar.xz
  -> Found lld-3.7.0.src.tar.xz.sig
  -> Found 0001-Fix-GetHostTriple-for-mingw-w64-in-msys.patch
  -> Found 0002-use-DESTDIR-on-windows.patch
  -> Found 0012-Set-the-x86-arch-name-to-i686-for-mingw-w64.patch
  -> Found 0013-mingw-w64-dont-have-dl-library.patch
  -> Found 0014-use-DESTDIR-on-windows.patch
  -> Found 0015-Fix-the-calling-convention-of-Mingw64-long-double-va.patch
  -> Found 0016-Teach-mingw-toolchain-driver-to-properly-emit-static.patch
  -> Found 0017-Fix-PR23472-by-emitting-initialized-variable-and-its.patch
  -> Found 0031-COFF-add-the-mingw-alias-for-ImageBase.patch
  -> Found 0032-PECOFF-add-the-mingw-alias-for-ImageBase.patch
  -> Found 0033-PECOFF-add-searchLibrary-function-with-sysroot-suppo.patch
  -> Found 0034-GNU-add-support-for-linking-PECOFF.patch
  -> Found 0041-libcxx-add-support-for-mingw-w64.patch
==> Validating source files with sha256sums...
    llvm-3.7.0.src.tar.xz ... Passed
    llvm-3.7.0.src.tar.xz.sig ... Skipped
    cfe-3.7.0.src.tar.xz ... Passed
    cfe-3.7.0.src.tar.xz.sig ... Skipped
    compiler-rt-3.7.0.src.tar.xz ... Passed
    compiler-rt-3.7.0.src.tar.xz.sig ... Skipped
    test-suite-3.7.0.src.tar.xz ... Passed
    test-suite-3.7.0.src.tar.xz.sig ... Skipped
    libcxx-3.7.0.src.tar.xz ... Passed
    libcxx-3.7.0.src.tar.xz.sig ... Skipped
    libcxxabi-3.7.0.src.tar.xz ... Passed
    libcxxabi-3.7.0.src.tar.xz.sig ... Skipped
    clang-tools-extra-3.7.0.src.tar.xz ... Passed
    clang-tools-extra-3.7.0.src.tar.xz.sig ... Skipped
    lld-3.7.0.src.tar.xz ... Passed
    lld-3.7.0.src.tar.xz.sig ... Skipped
    0001-Fix-GetHostTriple-for-mingw-w64-in-msys.patch ... Passed
    0002-use-DESTDIR-on-windows.patch ... Passed
    0012-Set-the-x86-arch-name-to-i686-for-mingw-w64.patch ... Passed
    0013-mingw-w64-dont-have-dl-library.patch ... Passed
    0014-use-DESTDIR-on-windows.patch ... Passed
    0015-Fix-the-calling-convention-of-Mingw64-long-double-va.patch ... Passed
    0016-Teach-mingw-toolchain-driver-to-properly-emit-static.patch ... Passed
    0017-Fix-PR23472-by-emitting-initialized-variable-and-its.patch ... Passed
    0031-COFF-add-the-mingw-alias-for-ImageBase.patch ... Passed
    0032-PECOFF-add-the-mingw-alias-for-ImageBase.patch ... Passed
    0033-PECOFF-add-searchLibrary-function-with-sysroot-suppo.patch ... Passed
    0034-GNU-add-support-for-linking-PECOFF.patch ... Passed
    0041-libcxx-add-support-for-mingw-w64.patch ... Passed
==> Verifying source file signatures with gpg...
    llvm-3.7.0.src.tar.xz ... FAILED (unknown public key 0FC3042E345AD05D)
    cfe-3.7.0.src.tar.xz ... FAILED (unknown public key 0FC3042E345AD05D)
    compiler-rt-3.7.0.src.tar.xz ... FAILED (unknown public key 0FC3042E345AD05D)
    test-suite-3.7.0.src.tar.xz ... FAILED (unknown public key 0FC3042E345AD05D)
    libcxx-3.7.0.src.tar.xz ... FAILED (unknown public key 0FC3042E345AD05D)
    libcxxabi-3.7.0.src.tar.xz ... FAILED (unknown public key 0FC3042E345AD05D)
    clang-tools-extra-3.7.0.src.tar.xz ... FAILED (unknown public key 0FC3042E345AD05D)
    lld-3.7.0.src.tar.xz ... FAILED (unknown public key 0FC3042E345AD05D)
==> ERROR: One or more PGP signatures could not be verified!

I just do makepkg-mingw --skippgpcheck -sLf, but I guess you guys accept a new certificate on system basis? Tested to compile the clang package again just to be sure, and it works fine.

@mingwandroid
Copy link

I'll get back to you later!

@eidheim
Copy link
Member Author

eidheim commented Dec 14, 2015

Temporary solution for MSYS2 users (replace x86_64 with i686 for 32-bit installs):

git clone git://github.com/Alexpux/MINGW-packages
cd MINGW-packages/mingw-w64-clang
makepkg-mingw -sLf --skippgpcheck
pacman -U mingw-w64-x86_64-llvm-3.7.0-8-any.pkg.tar.xz mingw-w64-x86_64-clang-3.7.0-8-any.pkg.tar.xz

@eidheim
Copy link
Member Author

eidheim commented Dec 20, 2015

@zalox do you have a version of Windows > 7? I have only Windows 7 on my virtual machines, and it seems like I do not get updates anymore from MSYS2. Might be related to msys2/MSYS2-packages#372. If you have Windows > 7, what is your output when doing:

pacman -Ss clang

? Of course after doing a pacman -Suy.

@zalox
Copy link
Member

zalox commented Dec 20, 2015 

$ pacman -Suy
:: Synchronizing package databases...
 mingw32 is up to date
 mingw64 is up to date
 msys is up to date
:: Starting full system upgrade...
 there is nothing to do
$ pacman -Ss clang
mingw32/mingw-w64-i686-clang 3.7.0-6
    C language family frontend for LLVM
mingw32/mingw-w64-i686-clang-analyzer 3.7.0-6
    A source code analysis framework (mingw-w64)
mingw32/mingw-w64-i686-clang-tools-extra 3.7.0-6
    Extra tools built using Clang's tooling APIs
mingw32/mingw-w64-i686-compiler-rt 3.7.0-6
    Runtime libraries for Clang and LLVM (mingw-w64)
mingw64/mingw-w64-x86_64-clang 3.7.0-6 [installed]
    C language family frontend for LLVM
mingw64/mingw-w64-x86_64-clang-analyzer 3.7.0-6
    A source code analysis framework (mingw-w64)
mingw64/mingw-w64-x86_64-clang-tools-extra 3.7.0-6
    Extra tools built using Clang's tooling APIs
mingw64/mingw-w64-x86_64-compiler-rt 3.7.0-6
    Runtime libraries for Clang and LLVM (mingw-w64)
msys/clang-svn 60106.1d5b05f-1
    C language family frontend for LLVM (mingw-w64)
msys/mingw-w64-cross-crt-clang-git 5.0.0.4592.90b8472-1 (mingw-w64-cross-toolchain mingw-w64-cross)
    MinGW-w64 CRT for cross-compiler

@zalox
Copy link
Member

zalox commented Dec 20, 2015

This is from Windows Server 2012.

@mingwandroid
Copy link

Urgh, sorry, I dropped the ball on this one! Let me re-read.

@mingwandroid
Copy link

I'm reworking our mingw-w64-clang* PKGBUILDs a bit at present, have been since I first commented on this issue, and always meant to finish it then get back to you!

But @eidheim now that I look at it, you need to do:

makepkg-mingw -sLf --skippgpcheck

instead of

makepkg-mingw --skippgpcheck -sLf

.. which didn't jump out at me until now; apologies

@eidheim
Copy link
Member Author

eidheim commented Dec 20, 2015

Ah splendid, thought it was a Windows 7 issue, but then everything is ok, and we just relax till you are done with the rework:)

@eidheim
Copy link
Member Author

eidheim commented Dec 20, 2015

The issue was that I got no updated clang packages when doing pacman -Suy, the makepkg-command worked, but I'll change it above like you said still.

@mingwandroid
Copy link

@eidheim Ah, what version do you have of them?

I know this isn't the right venue, but on your build instructions for Windows/MSYS2 at https://github.com/cppit/jucipp/blob/master/docs/install.md, you might want to adopt what we have with MSYS2_ARG_CONV_EXCL at:
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-jucipp-git/PKGBUILD#L51
so that you can use DESTDIR as-per:
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-jucipp-git/PKGBUILD#L63

@eidheim
Copy link
Member Author

eidheim commented Dec 20, 2015

Version 3.7.0-6 is installed through pacman, instead of latest 3.7.0-8 (https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-clang/PKGBUILD).

Thank you, I'll have a look at the package and see if I can improve the install documentation Tomorrow.

@mingwandroid
Copy link

@eidheim mingw-w64-clang-svn might be in a state to test (being an -svn package, it might not, obviously, being as I've not tested my last commit, doubly so!) .. still, I'd appreciate testing if you're in a position to do so.

@eidheim
Copy link
Member Author

eidheim commented Dec 21, 2015

@mingwandroid I'm mostly interested in the libclang headers and libraries, you can see the exceptions I have done for MSYS2 here:
https://github.com/cppit/jucipp/blob/master/src/cmake.cc#L81
https://github.com/cppit/jucipp/blob/master/src/source_clang.cc#L202

I am aware of the problem with hardcoded c:/msysw32 install path, will fix that once I figure out how to get the MSYS2 install path. Have been thinking of using the WD environment variable, and just remove the two last directories. Also, this problem might be fixed in your remake, so I'll just wait for that I'm thinking.

I was thinking about the mingw-w64-clang and not the mingw-w64-clang-svn package. Have not tried the mingw-w64-clang-svn package. But I could do that if you would like.

@zalox zalox added this to the 1.0.1 milestone Dec 21, 2015
@eidheim eidheim removed this from the 1.0.1 milestone Dec 21, 2015
@eidheim
Copy link
Member Author

eidheim commented Dec 26, 2015

Upgrade MSYS2 (new clang package released), recompile and reinstall juCi++, and this problem now goes away.

@eidheim eidheim closed this as completed Dec 26, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@eidheim eidheim

Labels
solved
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mingwandroid @zalox @eidheim