SIGSEGV when opening c/cpp/h files #155
Comments
|
Thanks for the excellent bug report! Hopefully we can get this resolved for you promptly. To handle a few of the points you brought up, in order:
I think the questions in the third point will lead us to what's going on with your startup crash. If you'd like, you can also add some logs to |
|
Thank you for your prompt answer and your enthusiasm! I would love to use color_coded again soon!
Also, I usually remove color_coded by using vundle's
a) Not a remote filesystem c) None of I didn't do too well here. I tried Too bad it's not color_coded, I hope it still helps... I need to close the file all the time because otherwise it usually does not get flushed before the sigsegv. Anyway, the log.txt file reads after running The reason that no "end1/end2/end3" shows up is because it crashes before exiting. Does this help? I am very confused and it's getting very late at night. I'll try harder on a new day. Maybe you have a more reliable method of logging in mind if this does not help at all? |
|
I have a more details on this issue: I have just installed a completely new Ubuntu 17.04 (downloaded from the official website onto a stick). Besides from setting my username, my region, my keyboard layout and alike, all I did was opening a terminal and using the following commands (copied from .bash_history without modification except misspelled commands): and then I just follow your steps: And finally, here is the .vimrc: If you have time, is there anything more of an information I can give to you? I am not sure what to do. On my main machine and on my laptop there is the same problem. A third machine, with its first couple command only installing vim and color_coded, also has the same issue. Is it maybe Ubuntu 17.04? Should I try a different version? Is something wrong with the installation steps I do? |
|
Thanks for the super detailed followup, @TravellingSalesPerson. It's a bummer this is still a problem for you and I will spin up a 17.04 machine so I can debug further. What you've done and reported has been super helpful and I certainly wouldn't ask you to reinstall your system again. :) I'm aiming to have this resolved over the weekend. |
|
You are actually lucky enough that I wanted to newly install that machine anyway, so do not worry. And you are even luckier, because I will do a fresh install on my laptop as well in the next couple days. |
Different vimsFollowing your steps, with an Ubuntu 17.04 vagrant machine, I've been able to reproduce this crash. However, Ubuntu 17.04 provides multiple vim options and I've found that not all of them have this crash.
After selecting vim-gtk3 again, and running this through gdb (add LocallyWhen I run it locally, and break at that line, I see: Ubuntu 17.04However, the Ubuntu machine gets something which makes a lot less sense: So the Ubuntu with one of the working vim buildsNaturally, the vim builds which don't crash also end up with sane output when I connect with gdb. The differenceSo, what's different? I don't know yet. The crash and weird logic is in boost, but the boost version isn't changing, since color_coded keeps its own boost to help avoid weird situations like this. Maybe the different vim versions are initializing things in different orders, which prevents some statics in boost from being initialized. Needs more investigation. Short-term workaroundUse one of the working vims in the list above. Hopefully we can get this crash sorted out promptly; any further research or info would help! |
|
Ok, I believe I see the source of the problem: These broken vims have their own boost dynamically linked in, which is a different version than the boost color_coded is statically linking. It seems like we're jumping back and forth between them, using the headers that color_coded has, but the dynamic library that vim has linked to. Even if color_coded were to dynamically link its boost parts, we still have the issue of double linkage here. To support these vims with boost, I think the only thing we can do is make sure we compile specifically against the version they're using and also make sure to link against that one as well. In other words, dynamically linking the system boost seems to be the only solution here (since the duplication will be resolved with both of them just referencing the same shared object). |
|
Very interesting find! Here also the output for vim-gnome (which crashes) for completeness: So, the solution is to no longer link to the boost color_coded comes with if the installed vim comes with one (and to link to the same as vim does instead)? Does this simply boil down to a small fix in the cmake files of color_coded? |
|
Unfortunately, it doesn't seem that simple. I've tried changing CMake to build with the dynamic system boost and I end up getting the same crash. My hypothesis could be incorrect, or not correct enough. If you'd like to tinker, I've pushed my hacks for building with the system boost to the Currently out of ideas. I'll take a break from it, for the rest of the day, and see if something comes to mind. |
|
I have tried your However, there is something else, much more interesting: Your I switched between master and system-boost multiple times and this result was always reproducible. So your fix seems to have worked, just for the other issue (#154) and not this one. :) I'd expect that you should be able to observe the same result in your test environment. If you do, then maybe the other issue (#154) is boost related but not this one? I remember having tried color_coded in the beginning of this year and it always crashed when opening vim (I don't remember if it was only for c/cpp/h files). I did get it fixed. It's a bummer that I do not remember how. I do remember for sure that I looked a lot into #119 because it was also a SIGSEGV and so I played around with installing and removing lua packages. However, I am not sure whether this is what fixed it in the end. Unfortunately, half a year later - now - I got the crash again when installing color_coded to a different machine. I retried what I remembered from the earlier experience but it did not work (which is what lead me here). One difference from back then to now is that used Ubuntu 16.04 or 16.10 and now 17.04. I have no idea if this anecdote of mine is of any help to you, but I thought I might share. |
|
For curiousness, I have tried a different Ubuntu version, because I remember I got color_coded working in the past. I now tried Ubuntu 16.04.3 LTS I installed it newly and besides from setting my username, my region, my keyboard layout and alike, all I did was opening a terminal and using the following commands (copied from .bash_history without modification): With the .vimrc: Therefore, color_coded does not crash when opening c/cpp/h files and neither does it crash when exiting files (issue #154) in Ubuntu 16.04. So, another workaround (besides using different versions of vim as you pointed out) is using a different Ubuntu version. I am sure you are curious about the output of In summary: -Working vim versions (e.g. vim-gtk) are not dynamically linked to boost (as Ubuntu 16.04 Therefore, the issue should definitely be boost related. Vim-gnome on 16.04 works and does not link to boost while vim-gnome on 17.04 does not work while linking to boost. Basically, if future 17.10 vim-gnome reverts to no longer link to boost, the issue is resolved for me by switching to Ubuntu 17.10 and marking vim-gnome on 17.04 as incompatible with color_coded. Also, recall from my previous post that your |
|
On Ubuntu 20.04, I had the same problem above. Unfortunately, I don't know the reason why it doesn't work well on the others. |
No matter whether opening a new file or an existing file, each of the following commands
result in:
Vi only shows up for a fraction of a second.
backtrace from GDB:
My vim version:
Very importantly, this problem does not happen when removing color_coded.
I am running a fresh install of Ubuntu 17.04 with the following vimrc
I have the same issue on my 2nd machine (also Ubuntu 17.04).
The symptoms are the same as in #119, but the stack trace is different and clang is 3.9.
I believe this issue could be related to #154, because I also get an invalid free whenever I close vim (except with c, cpp, h files because I don't even get to open them)
In case the two issues are indeed related, here is the output of valgrind when closing vim:
Where one line is color_coded related:
==19221== by 0x15096913: _GLOBAL__sub_I_path.cpp (in /home/tsp/.vim/bundle/color_coded/color_coded.so)The text was updated successfully, but these errors were encountered: