This is an archive of the discontinued LLVM Phabricator instance.

Fix ownership of FileManager in Tools
Needs ReviewPublic

Authored by resistor on Jan 6 2016, 12:48 AM.

Details

Reviewers
klimek
bkramer
Summary

Tooling suffered from a serious bug that caused double-destruction of FileManager objects. These objects were owned by the Tool, but then passed as raw pointers to the CompilerInstance which tried to take ownership of them.

This bug is asymptomatic today because of another bug of a horrible sequence of coincidences, which I discovered when trying to fix a different bug that perturbed the world enough to expose this.

Diff Detail

Repository
rL LLVM

Event Timeline

resistor updated this revision to Diff 44097.Jan 6 2016, 12:48 AM
resistor retitled this revision from to Fix ownership of FileManager in Tools.
resistor updated this object.
resistor set the repository for this revision to rL LLVM.
resistor updated this object.
klimek edited edge metadata.Jan 6 2016, 12:53 AM

Thx for fixing. What's the reason that the CompilerInstance wants ownership?

Thx for fixing. What's the reason that the CompilerInstance wants ownership?

I'm not an expert on the ownership model here, but it appears that CompilerInstance expects to hold ownership with an IntrusiveRefCntPtr. It then hands out raw pointers to the objects created under it.

There's nothing to indicate that it expects sole ownership. The problem manifests here, however, because the of the transfer method which passed through a raw pointer, so the two shared owners can end up with different reference counts.

klimek added a comment.Jan 6 2016, 1:17 AM

Thx for fixing. What's the reason that the CompilerInstance wants ownership?

I'm not an expert on the ownership model here, but it appears that CompilerInstance expects to hold ownership with an IntrusiveRefCntPtr. It then hands out raw pointers to the objects created under it.

There's nothing to indicate that it expects sole ownership. The problem manifests here, however, because the of the transfer method which passed through a raw pointer, so the two shared owners can end up with different reference counts.

I understand - my question is, why not instead take away ownership from CompilerInstance?

! In D15918#320308, @klimek wrote:

I understand - my question is, why not instead take away ownership from CompilerInstance?

That seemed like a much more logically disruptive change. I am not familiar with all the clients of CompilerInstance, and it's not clear to me that all of them want to take ownership of the FileManager.

klimek added a comment.Jan 7 2016, 7:17 AM

! In D15918#320308, @klimek wrote:

I understand - my question is, why not instead take away ownership from CompilerInstance?

That seemed like a much more logically disruptive change. I am not familiar with all the clients of CompilerInstance, and it's not clear to me that all of them want to take ownership of the FileManager.

Generally, it seems like FileManager should always outlive CompilerInstance.
As Chandler would say, "all uses of ref-counting in clang are bugs" - I won't go as far, but in this case I think he has a point...

I am not comfortable authoring a patch to do that, as I don't have a clear understanding of the clients involved, and have no means to verify its correctness.

I made an attempt to remove ownership from CompilerInstance, but ASTUnit has a massively complex relationship with FileManager, and foiled my attempt.

resistor edited edge metadata.Jan 10 2016, 11:43 PM
resistor added a subscriber: cfe-commits.