Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upeth-watcher fail #2099
eth-watcher fail #2099
Comments
This comment has been minimized.
This comment has been minimized.
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Same thing here |
This comment has been minimized.
This comment has been minimized.
|
Same here. |
This comment has been minimized.
This comment has been minimized.
|
same. i am getting lots of eth-watcher fails on both my planet and star. |
This comment has been minimized.
This comment has been minimized.
|
@philipcmonk @belisarius222 do we need these piers or do we have a lead on this bug ? |
This comment has been minimized.
This comment has been minimized.
|
I think it’s pretty reproducible. Booting a fresh ship would do it. I believe PM said a fresh pill would fix it going forward, but I don’t know how to solve the issue for people already running into this.
…Sent from my iPhone
On Dec 16, 2019, at 12:29 PM, Anthony Arroyo ***@***.***> wrote:
@philipcmonk @belisarius222 do we need these piers or do we have a lead on this bug ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
This comment has been minimized.
This comment has been minimized.
|
I tried a few experiments trying to restore older versions of |
This comment has been minimized.
This comment has been minimized.
|
This solves it for me: [edited]
I'll push a fixed pill soon which will fix this for new people. People who booted into this broken state should run the above two commands. This is a ford cache problem. @belisarius222, why doesn't ford recognize that a change to zuse should invalidate its cache? Why doesn't it throw away it's cache when it gets reloaded? Also, why doesn't ford say that all apps depend on zuse/arvo/hoon? |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
whoops, needs a percent argument. How about this:
|
This comment has been minimized.
This comment has been minimized.
|
Ford certainly should say that all apps depend on sys/hoon.hoon, sys/arvo.hoon, and sys/zuse.hoon. I'd be pretty surprised if it doesn't, since those files are in the "reef" that Ford uses as the initial compilation subject for %core builds.
I'm not sure we need to throw away old cache lines when Zuse reloads, since Ford's dependency tracking system should know that anything that depended on Zuse now has a changed dependency. The "cache promotion" logic that uses old cache lines as new ones should recognize this just like any other changed dependency and not propagate the cache.
Maybe there's a bug in this logic. The error was from rebuilding a live build, and for some reason clearing the cache fixed it. Failure to propagate a change to Zuse could exhibit this behavior, since cached build results built with old Zuse would still show up as valid.
Clearing the cache on +load shouldn't be strictly necessary unless we change Ford in a way that will break referential transparency — most don't. It's probably safer, though, as long as clearing the cache doesn't cause bail:meme on |reload.
—
~rovnys-ricfer
https://urbit.org
…On Mon, Dec 16, 2019 at 7:45 PM, Kenny Rowe < ***@***.*** > wrote:
Closed #2099 ( #2099 ).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (
#2099?email_source=notifications&email_token=AAGVR5MUGARBEYSPMIFD56TQZAOLFA5CNFSM4J242E7KYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOVQR4NJI#event-2888025765
) , or unsubscribe (
https://github.com/notifications/unsubscribe-auth/AAGVR5ILVC7FW3DQEOO5TN3QZAOLFANCNFSM4J242E7A
).
|
This comment has been minimized.
This comment has been minimized.
|
has it ever been the case that changing zuse.hoon caused all your apps to reload? If that's supposed to have been happening, then it's been a bug this whole time |
This comment has been minimized.
This comment has been minimized.
|
Yes, that should happen... so you're right, this is broken.
—
~rovnys-ricfer
https://urbit.org
…On Mon, Dec 16, 2019 at 8:22 PM, Philip Monk < ***@***.*** > wrote:
has it ever been the case that changing zuse.hoon caused all your apps to
reload? If that's supposed to have been happening, then it's been a bug
this whole time
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (
#2099?email_source=notifications&email_token=AAGVR5NAA35NOH3DV5K46L3QZAST3A5CNFSM4J242E7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHAZWSY#issuecomment-566336331
) , or unsubscribe (
https://github.com/notifications/unsubscribe-auth/AAGVR5NDBEN7KFRHUC5UP5TQZAST3ANCNFSM4J242E7A
).
|
This comment has been minimized.
This comment has been minimized.
|
adding %wipe 100 to goad crashes in ford on line 1791, probably on rebuilding the apps. If I take away the !. in ++reduce, the crash is on the ?< in +apply-blocks. |
This comment has been minimized.
This comment has been minimized.
|
Looks like somehow Ford thinks a build blocked on a sub-build that was already completed and in the build graph. The assertion is there as a sanity check that this never happens, and I've never seen it throw before (although maybe that's just because of the !.).
I'll look into this after the ames packet queue bug.
—
~rovnys-ricfer
https://urbit.org
…On Mon, Dec 16 2019 at 9:00 PM, Logan < ***@***.*** > wrote:
adding %wipe 100 to goad crashes in ford on line 1791, probably on
rebuilding the apps. If I take away the !. in ++reduce, the crash is on
the ?< in +apply-blocks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (
#2099?email_source=notifications&email_token=AAGVR5KFYYNLJX5JTBH6N4TQZAXFLA5CNFSM4J242E7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHA344Y#issuecomment-566345331
) , or unsubscribe (
https://github.com/notifications/unsubscribe-auth/AAGVR5LXRYZJGUHRVLES4RTQZAXFLANCNFSM4J242E7A
).
|
This comment has been minimized.
This comment has been minimized.
|
I think crashes in %drip updates from %clay invalidate those kinds of assumptions. |
This comment has been minimized.
This comment has been minimized.
|
Yeah, I think you're right. I think I'll go ahead and add some code to Ford to clear the build graph on +load and whenever Hoon, Arvo, or Zuse change. That should be dumb and safe, which are probably good adjectives for this part of the system.
—
~rovnys-ricfer
https://urbit.org
…On Tue, Dec 17, 2019 at 1:42 PM, Joe Bryan < ***@***.*** > wrote:
I think crashes in %drip updates from %clay invalidate those kinds of
assumptions.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (
#2099?email_source=notifications&email_token=AAGVR5IYRO3BIEIUSL2IAKTQZEMRNA5CNFSM4J242E7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHDRFMI#issuecomment-566694577
) , or unsubscribe (
https://github.com/notifications/unsubscribe-auth/AAGVR5IVO7Q7IG5B4ELRDKLQZEMRNANCNFSM4J242E7A
).
|

Getting
eth-watcher failedwhen booting a new ship for the first time. Not able to connect to the network.Using current version 0.10.1
%base-hash 0v1m.7thj6.bt9f0.kecmn.psn12.t5nic.mev4p.oe12v.erhcb.b9ddc.of4bg