Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Follow up to #46924, fix massive spurious failure when starting docker #47000

Merged
merged 1 commit into from
Dec 26, 2017

Conversation

kennytm
Copy link
Member

@kennytm kennytm commented Dec 25, 2017

It seems using fe80::/64 causes docker start to fail with "Address already in use". Try to change to a unique local address range instead.

fe80::/64 is a link-local address (similar to 169.254.0.0/16 in IPv4). Let's try to use a random "private network" address to see whether that fixes things.

cc #47002

r? @aidanhs

It seems using `fe80::/64` causes `docker start` to fail with "Address
already in use". Try to change to a unique local address range instead.
@kennytm kennytm added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Dec 25, 2017
@kennytm
Copy link
Member Author

kennytm commented Dec 25, 2017

@bors try

@bors
Copy link
Contributor

bors commented Dec 25, 2017

⌛ Trying commit 472a3c1 with merge 5ddec7adfa1883fd5f1db3984809cefb6cc2932b...

@kennytm
Copy link
Member Author

kennytm commented Dec 25, 2017

@bors r- try- retry

@kennytm kennytm changed the title [WIP] Follow up to #46924 Follow up to #46924, fix massive spurious failure when starting docker Dec 25, 2017
@kennytm
Copy link
Member Author

kennytm commented Dec 25, 2017

The docker has successfully been built on the try branch. Now I'm trying to check if it works on the auto branch. To check this, I'll r+ for confirmation, and then r- it after 20 minutes.

@bors r+

@bors
Copy link
Contributor

bors commented Dec 25, 2017

📌 Commit 472a3c1 has been approved by kennytm

@bors
Copy link
Contributor

bors commented Dec 25, 2017

⌛ Testing commit 472a3c1 with merge a555a3f87cad81e0aef4f08f9096bc3601c29e26...

@kennytm
Copy link
Member Author

kennytm commented Dec 25, 2017

@bors r- retry

@kennytm kennytm added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 25, 2017
@arielb1
Copy link
Contributor

arielb1 commented Dec 25, 2017

@bors r+ p=10

@bors
Copy link
Contributor

bors commented Dec 25, 2017

📌 Commit 472a3c1 has been approved by arielb1

@bors
Copy link
Contributor

bors commented Dec 25, 2017

⌛ Testing commit 472a3c1 with merge 7674ffb...

bors added a commit that referenced this pull request Dec 25, 2017
Follow up to #46924, fix massive spurious failure when starting docker

It seems using `fe80::/64` causes `docker start` to fail with "Address already in use". Try to change to a unique local address range instead.

`fe80::/64` is a link-local address (similar to `169.254.0.0/16` in IPv4). Let's try to use a random "private network" address to see whether that fixes things.

cc #47002

r? @aidanhs
@bors
Copy link
Contributor

bors commented Dec 25, 2017

💔 Test failed - status-appveyor

@kennytm
Copy link
Member Author

kennytm commented Dec 26, 2017

@bors retry

3 hour timeout.

@bors
Copy link
Contributor

bors commented Dec 26, 2017

⌛ Testing commit 472a3c1 with merge d21e176607e046614b1f2e661a0a98c8139ce87f...

@bors
Copy link
Contributor

bors commented Dec 26, 2017

💔 Test failed - status-travis

@kennytm
Copy link
Member Author

kennytm commented Dec 26, 2017

@bors retry

sccache segfault?!

@bors
Copy link
Contributor

bors commented Dec 26, 2017

⌛ Testing commit 472a3c1 with merge 2e83f3c...

bors added a commit that referenced this pull request Dec 26, 2017
Follow up to #46924, fix massive spurious failure when starting docker

It seems using `fe80::/64` causes `docker start` to fail with "Address already in use". Try to change to a unique local address range instead.

`fe80::/64` is a link-local address (similar to `169.254.0.0/16` in IPv4). Let's try to use a random "private network" address to see whether that fixes things.

cc #47002

r? @aidanhs
@bors
Copy link
Contributor

bors commented Dec 26, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: arielb1
Pushing 2e83f3c to master...

@bors bors merged commit 472a3c1 into rust-lang:master Dec 26, 2017
@aidanhs
Copy link
Member

aidanhs commented Dec 27, 2017

Reported sccache segfault, though I don't know if it was sccache's fault or if it was 'just' some failure cascading (mozilla/sccache#210)

@glandium
Copy link
Contributor

FWIW, we've had the lookForDIEsToKeep llvm-dsymutil crashes on Firefox. See https://bugzilla.mozilla.org/show_bug.cgi?id=1381043 and https://bugs.llvm.org/show_bug.cgi?id=33873 . It's fixed in llvm upstream, but the root cause in rustc probably still exists (it was obviously a llvm bug that it led to a crash, but the root cause was that rustc produces bad DWARF data).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants