{"action":"created","issue":{"url":"https://api.github.com/repos/rust-lang/cargo/issues/5444","repository_url":"https://api.github.com/repos/rust-lang/cargo","labels_url":"https://api.github.com/repos/rust-lang/cargo/issues/5444/labels{/name}","comments_url":"https://api.github.com/repos/rust-lang/cargo/issues/5444/comments","events_url":"https://api.github.com/repos/rust-lang/cargo/issues/5444/events","html_url":"https://github.com/rust-lang/cargo/issues/5444","id":319080960,"number":5444,"title":"Race condition when trying to compile a lib multiple times for different purposes.","user":{"login":"ehuss","id":43198,"avatar_url":"https://avatars0.githubusercontent.com/u/43198?v=4","gravatar_id":"","url":"https://api.github.com/users/ehuss","html_url":"https://github.com/ehuss","followers_url":"https://api.github.com/users/ehuss/followers","following_url":"https://api.github.com/users/ehuss/following{/other_user}","gists_url":"https://api.github.com/users/ehuss/gists{/gist_id}","starred_url":"https://api.github.com/users/ehuss/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ehuss/subscriptions","organizations_url":"https://api.github.com/users/ehuss/orgs","repos_url":"https://api.github.com/users/ehuss/repos","events_url":"https://api.github.com/users/ehuss/events{/privacy}","received_events_url":"https://api.github.com/users/ehuss/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2018-05-01T00:33:18Z","updated_at":"2018-05-02T16:04:14Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"As part of #5384 I created some circumstances where the same lib may be built concurrently with different settings.  I thought this would be safe since they have different hashes in the filename, but I neglected to address this case when the library is hardlinked.  There is a race condition in `hardlink_or_copy` where one compilation will stomp on another via the hardlink.\r\n\r\n<details><summary>Details for the curious.</summary>\r\n<ol>\r\n<li> One compilation creates a hardlink.\r\n<li> The other compilation fails to create a hardlink with EEXIST.\r\n<li> 2nd compilation copies its lib into the existing hardlink, modifying the first one's contents.\r\n</ol>\r\n</details>\r\n\r\n<p>\r\n\r\nThis can happen in a variety of situations (mainly with `panic`), but here is a small repro:\r\n```\r\ncargo new --lib stomp\r\ncd stomp\r\ncat >> Cargo.toml <<EOL\r\n[profile.dev]\r\npanic = \"abort\"\r\nEOL\r\ncat > src/main.rs <<EOL\r\nextern crate stomp;\r\nfn main() {}\r\nEOL\r\n\r\n# This will fail some of the time on some platforms with wrong panic strategy.\r\n# Note: This requires #5384.  Earlier versions would fail 100% of the time.\r\n# This attempts to build `lib.rs` twice at the same time, once with `panic` \r\n# and once without (for tests).\r\ncargo build --all-targets -v\r\n```\r\n\r\nI'm trying to think of a fix, but I haven't come up with anything, yet.  Generally I'm thinking that these \"non-panic\" dependencies should not be hard linked at all, but there's no obvious way to detect when a `Unit` is one of these.  We could add a flag to `Unit` to detect this scenario, but that would require adding some extra de-duplication logic and generally seems a little too complex.\r\n\r\nI don't think it is worth it to try to fix the race condition itself since that is very tricky, and would end up with a random lib in the output directory anyway.\r\n\r\nI'll keep trying to think of a solution, but if anyone has any thoughts I'd be happy to hear.\r\n"},"comment":{"url":"https://api.github.com/repos/rust-lang/cargo/issues/comments/386030661","html_url":"https://github.com/rust-lang/cargo/issues/5444#issuecomment-386030661","issue_url":"https://api.github.com/repos/rust-lang/cargo/issues/5444","id":386030661,"user":{"login":"ehuss","id":43198,"avatar_url":"https://avatars0.githubusercontent.com/u/43198?v=4","gravatar_id":"","url":"https://api.github.com/users/ehuss","html_url":"https://github.com/ehuss","followers_url":"https://api.github.com/users/ehuss/followers","following_url":"https://api.github.com/users/ehuss/following{/other_user}","gists_url":"https://api.github.com/users/ehuss/gists{/gist_id}","starred_url":"https://api.github.com/users/ehuss/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ehuss/subscriptions","organizations_url":"https://api.github.com/users/ehuss/orgs","repos_url":"https://api.github.com/users/ehuss/repos","events_url":"https://api.github.com/users/ehuss/events{/privacy}","received_events_url":"https://api.github.com/users/ehuss/received_events","type":"User","site_admin":false},"created_at":"2018-05-02T16:04:14Z","updated_at":"2018-05-02T16:04:14Z","author_association":"CONTRIBUTOR","body":"> If we stopped hardlinking rlibs?\r\n\r\nIn my tests, other output types have the same problem.  (dylib is particularly broken since it doesn't have a hash in the filename.)\r\n\r\nAnother idea I was thinking about is only hardlinking the top-level targets (essentially the targets created in `generate_targets()`).  Do you think that would be a problem?  That would skip hardlinking implied dependencies in a few cases (like `cargo build --bin foo` would no longer link the lib, but if you want the lib you can just add `--lib`, or just run `cargo build` with no arguments).\r\n"}}
{"actor":{"display_login":"ehuss"}}