progress bar desync #1967
Comments
|
I think something else involved here than |
|
Oh certainly. I think it was more incidental that I had installed 1.37.0 before updating all the other toolchains. |
|
@rbtcollins Do you have any idea how this could have happened? |
|
Some observations:
|
|
So we have a hygiene problem here which I went 'lalalalala' at when I started improving IO, but perhaps its time to tackle. The lack of a newline after the 0s before the 'info' statement. That suggests we haven't closed off the progress bar, which happens as a kind of hack/thunk around the decompressing/extraction of the tars to disk. Checking exactly where the newlines are meant to be emitted and working back would be appropriate. There's no reference counting involved per se, but there is now threaded logic and I suppose the bug must lie in one of those interactions. The progress bar then gets reused for the next component by receiving a new event through the pub-sub system, which resets its state, and things proceed. The hygiene problem is that the type system really doesn't enforce any sort of correct use of this state machine, because things are too abstracted out. Have we done a release recently? E.g. is the threaded IO code enabled on this machine, or is it still just the threaded close logic? |
|
We've not done a new release yet, so the threading is only for the close logic currently. |
|
I wonder if the OP has encountered this in any more recent |
|
I haven't seen it again, but is there any cause for thinking it has been fixed? I suspect this is more a rare occurrence than something I could reliably check for. |
|
@mathstuf I was wondering based on @rbtcollins 's question about whether we'd released the threaded IO code or not. Since we have done so since August, I was hoping that might have fixed it. If you've only ever seen this once rather than reproducibly, then I guess this stays open until and unless we know we've done something we think fixes such an issue. Thanks. |
|
As part of #2121 I fixed a situation where we could leave a download tracker unfinalised. I believe that should resolve this as I couldn't spot any other pathways which could have this effect. If, after 1.21.0 is out, you still have this issue, please reopen or file a fresh one. Thanks, D. |
Problem
This is more an observation than a detailed issue report. I'd treat it as a BOLO for some underlying problem.
During an update, it seems that a component (clippy) update came in during a progress update. The next line had a really weird progress status at that point:
The progress report is just internally inconsistent. This, to me, indicates some kind of race, underflow and/or I/O locking bug lurking around.
Full command output
Steps
rustup updateMaybe something else is involved here?Possible Solution(s)
Something is allowing interleaved output and the progress bar seems to get confused at that point (assuming causation from correlation here).
Notes
Output of
rustup --version: rustup 1.18.3 (435397f 2019-05-22)Output of
rustup show:The text was updated successfully, but these errors were encountered: