SIGSEGV after moving to clang 3.8

[alientechnology]

I just recompiled color_coded it downloaded clang 3.8 by itself and now i'm getting segfault in vim just by opening any c/c++ file. Well backtrace doesn't look really libclang related for me, but I'm not shure.

I use last vim from git on ubuntu (gvim - with gnome libs).
Backtrace from gdb:

#0  0x00007f01acad9597 in kill () at ../sysdeps/unix/syscall-template.S:81
No locals.
#1  0x00000000005386fb in mch_exit ()
No symbol table info available.
#2  <signal handler called>
No locals.
#3  __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:30
No locals.
#4  0x00007f01a0658b91 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.3.so.0
No symbol table info available.
#5  0x00007f01a064abb4 in lua_setglobal () from /usr/lib/x86_64-linux-gnu/liblua5.3.so.0
No symbol table info available.
#6  0x00007f01a08928c9 in luaopen_color_coded () from /home/freeman/.vim/bundle/color_coded/color_coded.so
No symbol table info available.
#7  0x00007f01ade3f92d in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
No symbol table info available.
#8  0x00007f01ade3fc62 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
No symbol table info available.
#9  0x00007f01ade3bd0b in lua_callk () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
No symbol table info available.
#10 0x00007f01ade56c47 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
No symbol table info available.
#11 0x00007f01ade3f92d in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
No symbol table info available.
#12 0x00007f01ade3fc62 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
No symbol table info available.
#13 0x00007f01ade3f2af in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
No symbol table info available.
#14 0x00007f01ade3feb1 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
No symbol table info available.
#15 0x00007f01ade3bdd1 in lua_pcallk () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
No symbol table info available.
#16 0x00007f01ade4f427 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
No symbol table info available.
#17 0x00007f01ade3f92d in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#18 0x00007f01ade4b53d in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
No symbol table info available.
#19 0x00007f01ade3fc6e in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
No symbol table info available.
#20 0x00007f01ade3f2af in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
No symbol table info available.
#21 0x00007f01ade3feb1 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
No symbol table info available.
#22 0x00007f01ade3bdd1 in lua_pcallk () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
No symbol table info available.
#23 0x00000000005e0530 in ex_lua ()
No symbol table info available.
#24 0x00000000004a0698 in do_cmdline ()
No symbol table info available.
#25 0x000000000047491d in call_func ()
No symbol table info available.
#26 0x00000000004791fc in ?? ()
No symbol table info available.
#27 0x0000000000477a56 in ?? ()
No symbol table info available.
#28 0x0000000000477c94 in ?? ()
No symbol table info available.
#29 0x0000000000477f33 in ?? ()
No symbol table info available.
#30 0x0000000000478b84 in ?? ()
No symbol table info available.
#31 0x0000000000478d14 in ?? ()
No symbol table info available.
#32 0x000000000047929b in ?? ()
No symbol table info available.
#33 0x0000000000480991 in ex_let ()
No symbol table info available.
#34 0x00000000004a0698 in do_cmdline ()
No symbol table info available.
#35 0x0000000000494df2 in do_source ()
No symbol table info available.
#36 0x00000000004957ac in ?? ()
No symbol table info available.
#37 0x00000000004a0698 in do_cmdline ()
No symbol table info available.
#38 0x00000000004807ca in ex_execute ()
No symbol table info available.
#39 0x00000000004a0698 in do_cmdline ()
No symbol table info available.
#40 0x000000000047491d in call_func ()
No symbol table info available.
#41 0x00000000004791fc in ?? ()
No symbol table info available.
#42 0x000000000048126a in ex_call ()
No symbol table info available.
#43 0x00000000004a0698 in do_cmdline ()
No symbol table info available.
#44 0x000000000047491d in call_func ()
No symbol table info available.
No symbol table info available.
#46 0x000000000048126a in ex_call ()
No symbol table info available.
#47 0x00000000004a0698 in do_cmdline ()
No symbol table info available.
#48 0x000000000047491d in call_func ()
No symbol table info available.
#49 0x00000000004791fc in ?? ()
No symbol table info available.
#50 0x000000000048126a in ex_call ()
No symbol table info available.
#51 0x00000000004a0698 in do_cmdline ()
No symbol table info available.
#52 0x000000000047491d in call_func ()
No symbol table info available.
#53 0x00000000004791fc in ?? ()
No symbol table info available.
#54 0x000000000048126a in ex_call ()
No symbol table info available.
#55 0x00000000004a0698 in do_cmdline ()
No symbol table info available.
#56 0x00000000004b74a5 in ?? ()
No symbol table info available.
#57 0x00000000004b8054 in apply_autocmds ()
No symbol table info available.
#58 0x000000000052e1a7 in ?? ()
No symbol table info available.
#59 0x0000000000535226 in set_option_value ()
No symbol table info available.
#60 0x00000000004a0698 in do_cmdline ()
No symbol table info available.
#61 0x00000000004b74a5 in ?? ()
No symbol table info available.
#62 0x00000000004bd07c in readfile ()
No symbol table info available.
#63 0x00000000004436df in open_buffer ()
No symbol table info available.
#64 0x000000000043b5d2 in main ()
No symbol table info available.

[jeaye]

Yikes; I know multiple people, myself included, have tested 3.8.0 on Ubuntu, but I don't know about testing gvim; I only tested terminal vim, but I also built from git. Since you're running the latest vim and you're using dynamic linking for lua, it rules out the two primary suspects. Please verify that you don't have luajit compiled into vim (it looks like you don't, but check).

[alientechnology]

Thanks for fast answer. Luajit was first what i thought about, but i doublechecked, and I don't have it. Who is the second suspect? I see that vim built with lua 5.2 and color coded tryes to use lua5.3, may it be the problem?

[alientechnology]

I figured out what was my problem, i had both lua 5.2 and 5.3 libs in my system, so vim was built with 5.2, but color coded was building with 5.3 for some reason, maybe cmake finds just newest one. Building it with lua5.2 fixed the problem. What is the best way to link color_coded.so with lua 5.2 having different versions in system?

[jeaye]

Hm, it seems like that's exactly the issue: color_coded just assumes the latest lua is what it should use. In general, I think that's a safe bet, but it might be better to try to procedurally figure out what vim is using and use that.

At the very least, we can expose some environment variable to cmake which will override the preferred lua version. Thanks for following up with this and investigating it to closure.

[alientechnology]

Yeah, having exposed cmake variable will be nice. And by the way, consider adding /usr/lib/llvm-3.8/lib to SEARCH_PATHS if -DCUSTOM_CLANG specified, for building with system installed clang 7.8, now it looks up only from 3.4 upto 3.6.

[jeaye]

#114 changes that all quite a bit, so I'm waiting for it to be ready.

[safiire]

I just compiled vim 7.4 with lua 5.2.4_3 (installed from homebrew) into /usr/local, I only have this version of lua and no luajit.
I then compile color_coded, it grabs clang 3.8 and succeeds building.

Then when I open any c++ file, everything is fine at first and color_coded works, but not before long and it will crash here:

gdb$
#0  0x00007fff832a3716 in __psynch_cvwait () from /usr/lib/system/libsystem_kernel.dylib
#1  0x00007fff88eb6c3b in _pthread_cond_wait () from /usr/lib/system/libsystem_pthread.dylib
#2  0x00007fff8fa2dd43 in std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) () from /usr/lib/libc++.1.dylib
#3  0x0000000100696e8b in color_coded::async::queue<color_coded::async::task, color_coded::async::result>::work() () from /Users/safiire/.vim/bundle/color_coded/color_coded.so
#4  0x00000001006974c6 in void* std::__1::__thread_proxy<std::__1::tuple<std::__1::__bind<void (color_coded::async::queue<color_coded::async::task, color_coded::async::result>::*)(), color_coded::async::queue<color_coded::async::task, color_coded::async::result>*> > >(void*) () from /Users/safiire/.vim/bundle/color_coded/color_coded.so
#5  0x00007fff88eb4899 in _pthread_body () from /usr/lib/system/libsystem_pthread.dylib
#6  0x00007fff88eb472a in _pthread_start () from /usr/lib/system/libsystem_pthread.dylib
#7  0x00007fff88eb8fc9 in thread_start () from /usr/lib/system/libsystem_pthread.dylib
#8  0x0000000000000000 in ?? ()

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled May 21 2016 18:41:16)
MacOS X (unix) version
Included patches: 1-1832
Compiled by safiire@charmander
...
+dialog_con      +lua             +rightleft       +windows

[safiire]

After looking through other issues I realize that it is actually the same issue as #61 and turning off beeps prevents the crash. I have escape mapped to jj, and if I press it too much I guess the terminal beeps, though it doesn't actually make the sound. It also happens when I push j multiple times after the cursor is at the bottom of the file.

[sabastiaan]

I'm getting an SEGV singal on startup while using clang 3.8 (haven't tried others yet). Is there a fix for this?

[sabastiaan]

Hey @jeaye ,

Any updates on this?

[jeaye]

@sabastiaan Is this still an issue on clang 3.9?

[sabastiaan]

@jeaye I don't have clang 3.9 currently on my machine, I'll post the results sometime this evening.

[jeaye]

Closing, since this went stale.