Skip to content


Subversion checkout URL

You can clone with
Download ZIP


We shouldn't use vim API inside clang_complete threads. #236

wants to merge 1 commit into from

2 participants


This may be the cause for issue #228, and several others.


Looks reasonable.

Does this fix an actual issue for you? I was told that using the vim API from threads may cause problems, however
I could never see any problems on my side. Hence, it would be very interesting if you can reproduce such problems and if you can verify that the above fix actually solves them.


Wait! Moving the warmup cache code under the debug flag does not sound reasonable at all. As noted in the other pull request, I would be a lot more comfortable with a separate option clang_cache_warmup that is off by default. Not being able to control debugging and the warmup cache independently is annoying. Also having the debug flag changing more than just a couple of pretty print statements is more than unexpected. This will e.g. cause all timings that have been made in debug mode to be entirely different than the once in non-debug mode.

Can you remove this line from the patch and add the new parameter in a separate change?


I just realized there slipped a change in that is not reasonable. It is unrelated to the pull request topic. Even I agree that it is good to disable the warmup code by default, I don't think using the debug option is the right way to do so.


Hum, strange, moving the WarmupCache into debug mode wasn't intended… Will remove that change before pushing.

As for the reproducibility of that "bug", when a thread tries to use vim function, vim will simply segfault randomly without giving you any clue about what happened… Since I'm pretty sure that all the "vim segfault" bugs that we're seeing recently are due to threads using vim API, I've started looking into the code to remove those, this was the most obvious wrong code :)

edit: Thanks for the review btw.

@Rip-Rip Rip-Rip closed this
@Rip-Rip Rip-Rip deleted the no-vim-api-in-thread branch

Just to recheck. Do you experience this random failures yourself? Was this patch enough to remove them? I mean, can we now expect that this random crashes have been fixed or was this an intermediate step to the goal of removing all vim calls within threads? I am asking as I currently have no way of helping with these bug reports, as I can not reproduce them locally.


This change was just a step, in debug mode, vim is always segfaulting for me, so new fixes are coming :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
This page is out of date. Refresh to see the latest.
Showing with 6 additions and 5 deletions.
  1. +6 −5 plugin/
11 plugin/
@@ -402,14 +402,13 @@ def formatResult(result):
class CompleteThread(threading.Thread):
- def __init__(self, line, column, currentFile, fileName, timer=None):
+ def __init__(self, line, column, currentFile, fileName, params, timer=None):
self.line = line
self.column = column
self.currentFile = currentFile
self.fileName = fileName
self.result = None
- params = getCompileParams(fileName)
self.args = params['args']
self.cwd = params['cwd']
self.timer = timer
@@ -437,8 +436,10 @@ def run(self):
def WarmupCache():
global debug
debug = int(vim.eval("g:clang_debug")) == 1
- t = CompleteThread(-1, -1, getCurrentFile(),
- t.start()
+ if debug:
+ t = CompleteThread(-1, -1, getCurrentFile(),,
+ getCompileParams(
+ t.start()
def getCurrentCompletions(base):
@@ -451,7 +452,7 @@ def getCurrentCompletions(base):
timer = CodeCompleteTimer(debug,, line, column)
t = CompleteThread(line, column, getCurrentFile(),,
- timer)
+ getCompileParams(, timer)
while t.isAlive():
Something went wrong with that request. Please try again.