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

Intermittent, but more repeatable, hang sending/receiving a large buffer over TCP #616

Closed
aseering opened this issue Jul 2, 2016 · 29 comments

Comments

@aseering
Copy link
Contributor

commented Jul 2, 2016

The symptoms of this issue are similar to those described in #493 . However, the reproducer on that issue has been fixed; this one still reproduces as of build 14376.

Setting up this reproducer is unfortunately a little bit involved... Hopefully manageable, though.

Initial Setup -- run the following commands in WSL:

sudo apt-get install build-essential git cmake libboost-all-dev
git clone https://github.com/eidheim/Simple-Web-Server.git
cd Simple-Web-Server
cmake .
make -j4
dd if=/dev/zero of=web/big.dat bs=1048576 count=300

Note that this setup relies on code from this github repository. I have no affiliation with the repository; I found it while looking around online for pre-existing code that did a specific set of things.

Steps to reproduce:

  • Open up two WSL console windows
  • In one, do cd Simple-Web-Server ; ./http_examples. Give the server process a couple seconds to start up.
  • In the other, do curl http://localhost:8080/big.dat >/dev/null

Expected / what happens on real-Ubuntu:

  • curl is successfully able to download the big file

Actual / what happens in WSL:

  • curl occasionally finishes the download, but usually hangs partway through
@aseering

This comment has been minimized.

Copy link
Contributor Author

commented Jul 2, 2016

Possibly of note: When I tried the same steps except using curl.exe in a Windows console, I also experienced a hang. However, it was much more intermittent; I had to run the command maybe half a dozen times before I experienced the hang.

@aseering

This comment has been minimized.

Copy link
Contributor Author

commented Jul 2, 2016

strace output from when the download is going successfully:

./http_example:

...
[pid   238] epoll_wait(4, {}, 128, 0)   = 0
[pid   238] read(13, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072
[pid   238] sendmsg(12, {msg_name(0)=NULL, msg_iov(1)=[{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 65536
[pid   238] epoll_wait(4, {}, 128, 0)   = 0
[pid   238] sendmsg(12, {msg_name(0)=NULL, msg_iov(1)=[{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 65536
[pid   238] epoll_wait(4, {}, 128, 0)   = 0
[pid   238] read(13, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072
[pid   238] sendmsg(12, {msg_name(0)=NULL, msg_iov(1)=[{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 65536
[pid   238] epoll_wait(4, {}, 128, 0)   = 0
[pid   238] sendmsg(12, {msg_name(0)=NULL, msg_iov(1)=[{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 65536
...

curl:

...
clock_gettime(CLOCK_MONOTONIC, {2137, 771882000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2137, 772059000}) = 0
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
clock_gettime(CLOCK_MONOTONIC, {2137, 781795000}) = 0
poll([{fd=3, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 16384, 0, NULL, NULL) = 16384
write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192
write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192
clock_gettime(CLOCK_MONOTONIC, {2137, 786292000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2137, 786519000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2137, 786871000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2137, 787168000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2137, 787430000}) = 0
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
clock_gettime(CLOCK_MONOTONIC, {2137, 787932000}) = 0
poll([{fd=3, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 16384, 0, NULL, NULL) = 16384
write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192
write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192
clock_gettime(CLOCK_MONOTONIC, {2137, 788674000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2137, 788805000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2137, 788936000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2137, 789066000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2137, 789196000}) = 0
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
clock_gettime(CLOCK_MONOTONIC, {2137, 791811000}) = 0
poll([{fd=3, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 16384, 0, NULL, NULL) = 16384
write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192
write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192
clock_gettime(CLOCK_MONOTONIC, {2137, 792807000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2137, 793153000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2137, 793503000}) = 0
...
@aseering

This comment has been minimized.

Copy link
Contributor Author

commented Jul 2, 2016

strace output from after the download has hung:

./http_example:

...
[pid   250] gettimeofday({1467430456, 874565}, NULL) = 0
[pid   250] gettimeofday({1467430456, 874565}, NULL) = 0
[pid   250] timerfd_settime(5, 0, {it_interval={0, 0}, it_value={289, 684622000}}, {it_interval={0, 0}, it_value={289, 688717000}}) = 0
[pid   250] epoll_wait(4, {{EPOLLIN, {u32=17995988, u64=17995988}}}, 128, -1) = 1
[pid   250] gettimeofday({1467430456, 875562}, NULL) = 0
[pid   250] gettimeofday({1467430456, 875562}, NULL) = 0
[pid   250] timerfd_settime(5, 0, {it_interval={0, 0}, it_value={289, 683625000}}, {it_interval={0, 0}, it_value={289, 684803000}}) = 0
[pid   250] epoll_wait(4, {{EPOLLIN, {u32=17995988, u64=17995988}}}, 128, -1) = 1
[pid   250] gettimeofday({1467430456, 876566}, NULL) = 0
[pid   250] gettimeofday({1467430456, 876566}, NULL) = 0
[pid   250] timerfd_settime(5, 0, {it_interval={0, 0}, it_value={289, 682621000}}, {it_interval={0, 0}, it_value={289, 683635000}}) = 0
[pid   250] epoll_wait(4, {{EPOLLIN, {u32=17995988, u64=17995988}}}, 128, -1) = 1
[pid   250] gettimeofday({1467430456, 876566}, NULL) = 0
[pid   250] gettimeofday({1467430456, 877562}, NULL) = 0
[pid   250] timerfd_settime(5, 0, {it_interval={0, 0}, it_value={289, 681625000}}, {it_interval={0, 0}, it_value={289, 682779000}}) = 0
[pid   250] epoll_wait(4, {{EPOLLIN, {u32=17995988, u64=17995988}}}, 128, -1) = 1
[pid   250] gettimeofday({1467430456, 877562}, NULL) = 0
[pid   250] gettimeofday({1467430456, 877562}, NULL) = 0
[pid   250] timerfd_settime(5, 0, {it_interval={0, 0}, it_value={289, 681625000}}, {it_interval={0, 0}, it_value={289, 682000000}}) = 0
[pid   250] epoll_wait(4, {{EPOLLIN, {u32=17995988, u64=17995988}}}, 128, -1) = 1
[pid   250] gettimeofday({1467430456, 878561}, NULL) = 0
[pid   250] gettimeofday({1467430456, 878561}, NULL) = 0
...

curl:

...
clock_gettime(CLOCK_MONOTONIC, {2495, 563635000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2495, 563801000}) = 0
poll([{fd=3, events=POLLIN}], 1, 1000)  = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {2496, 564601000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2496, 564758000}) = 0
poll([{fd=3, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {2496, 565142000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2496, 565279000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2496, 565450000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2496, 565579000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2496, 565709000}) = 0
poll([{fd=3, events=POLLIN}], 1, 1000)  = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {2497, 566371000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2497, 566510000}) = 0
poll([{fd=3, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {2497, 566797000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2497, 566928000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2497, 567054000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2497, 567203000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2497, 567338000}) = 0
poll([{fd=3, events=POLLIN}], 1, 1000)  = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {2498, 567866000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2498, 568004000}) = 0
poll([{fd=3, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {2498, 568290000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2498, 568419000}) = 0
clock_gettime(CLOCK_MONOTONIC, {2498, 568548000}) = 0
...

Note that ./http_example's strace output is spewing out much faster than I can read it, but curl is mostly idle and emits a bunch of syscalls about once per second.

@aseering

This comment has been minimized.

Copy link
Contributor Author

commented Jul 2, 2016

Interestingly, if I just leave ./http_example to its own devices, after a few seconds its strace output starts spewing:

...
[pid   274] epoll_wait(4, {{EPOLLIN, {u32=20240596, u64=20240596}}}, 128, -1) = 1
[pid   274] timerfd_settime(5, 0, {it_interval={0, 0}, it_value={300, 0}}, {it_interval={0, 0}, it_value={299, 999661000}}) = 0
[pid   274] epoll_wait(4, {{EPOLLIN, {u32=20240596, u64=20240596}}}, 128, -1) = 1
[pid   274] timerfd_settime(5, 0, {it_interval={0, 0}, it_value={300, 0}}, {it_interval={0, 0}, it_value={299, 999709000}}) = 0
[pid   274] epoll_wait(4, {{EPOLLIN, {u32=20240596, u64=20240596}}}, 128, -1) = 1
[pid   274] timerfd_settime(5, 0, {it_interval={0, 0}, it_value={300, 0}}, {it_interval={0, 0}, it_value={299, 999684000}}) = 0
[pid   274] epoll_wait(4, {{EPOLLIN, {u32=20240596, u64=20240596}}}, 128, -1) = 1
[pid   274] timerfd_settime(5, 0, {it_interval={0, 0}, it_value={300, 0}}, {it_interval={0, 0}, it_value={299, 999614000}}) = 0
...

In contrast, on a real Ubuntu machine, its strace output looks like:

...
[pid 19646] write(1, "John Smith\n", 11John Smith
 <unfinished ...>
[pid 19647] epoll_wait(4,  <unfinished ...>
[pid 19646] <... write resumed> )       = 11
[pid 19647] <... epoll_wait resumed> {}, 128, 0) = 0
[pid 19646] futex(0x7f9fdfa929d0, FUTEX_WAIT, 19647, NULL <unfinished ...>
[pid 19647] getpeername(11, {sa_family=AF_INET, sin_port=htons(33924), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
[pid 19647] getpeername(11, {sa_family=AF_INET, sin_port=htons(33924), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
[pid 19647] timerfd_settime(5, 0, {it_interval={0, 0}, it_value={4, 999984000}}, {it_interval={140324628927456, 6151308}, it_value={140324500422152, 15922064}}) = 0
[pid 19647] recvmsg(11, 0x7f9fdfa90e90, 0) = -1 EAGAIN (Resource temporarily unavailable)
[pid 19647] epoll_wait(4, {}, 128, 0)   = 0
[pid 19647] epoll_wait(4, {{EPOLLIN, {u32=15922404, u64=15922404}}}, 128, -1) = 1
[pid 19647] timerfd_settime(5, 0, {it_interval={0, 0}, it_value={300, 0}}, {it_interval={140324500408512, 140324500419232}, it_value={140324628927808, 6202077}}) = 0
[pid 19647] shutdown(11, SHUT_RDWR)     = 0
[pid 19647] epoll_ctl(4, EPOLL_CTL_DEL, 11, {0, {u32=0, u64=0}}) = 0
[pid 19647] close(11)                   = 0
[pid 19647] epoll_wait(4, {}, 128, 0)   = 0
[pid 19647] epoll_wait(4,

(it stops here; no further syscalls are performed until the server process receives an HTTP connection.)

@aseering

This comment has been minimized.

Copy link
Contributor Author

commented Jul 2, 2016

For the record, all straces on the ./http_example process were performed as strace -ff ./http_example. (It's mulitithreaded, but more-or-less only has one thread active at a time in this reproducer.)

@sunilmut

This comment has been minimized.

Copy link
Member

commented Jul 5, 2016

Thanks @aseering for reporting this and the specific repro, really helpful! I will look into this one.

@aseering

This comment has been minimized.

Copy link
Contributor Author

commented Jul 6, 2016

No problem @sunilmut ! Let me know if the reproducer is working for you, if you need anything else, etc.

@benhillis benhillis added the network label Jul 7, 2016

@aseering

This comment has been minimized.

Copy link
Contributor Author

commented Jul 31, 2016

@sunilmut -- just checking, did you ever have a chance to look into this? It still affects me, and it sounds like it might be affecting others as well ( #575 ).

I know y'all are busy with the anniversary release, but I'd really appreciate it (and I suspect others would as well) if this were on your post-release ToDo list.

@aseering

This comment has been minimized.

Copy link
Contributor Author

commented Oct 30, 2016

FYI -- this still happens in build 14955 and with Ubuntu 16.04.

Interestingly, while the download is hung, I observe high CPU utilization. Also interestingly, unlike in #610 , this time the utilization is in Linux-space. Specifically, the ./http_examples binary is using lots of CPU. I believe that's not its intent; I believe it's at least trying to do efficient asynchronous I/O (though its implementation is rather complicated, thank you Boost :-) )

@aseering

This comment has been minimized.

Copy link
Contributor Author

commented Oct 30, 2016

@sunilmut @benhillis -- sorry to keep bugging you on this ticket -- some questions:

  • Is it useful for me to post (on an ongoing basis) that the reproducer for this issue affects recent builds? I don't want to spam y'all, but I do want to confirm that, among all the great fixes that you've posted so far for other issues, none of them has happened to address this one yet.
  • It sounds like you looked into this over the summer. Do you have any pointers / suggestions for things that might lead to a workaround? Any technical insights about what's going on? (Even if it's not something we as users can do anything about; I'm just curious :-) )
  • Could you share anything about where this collection of issues is on your radar? Do you have telemetry indicating that it's a frequent thing? Is it just the folks who've reported issues like this on github? (Order of a dozen such github reports so far; not all that many in the grand scheme of things.)

If it's just me and if it's a difficult fix, I'll focus on finding a workaround. If it's lots of people and not such a hard fix, then I'll bounce at you folks and do what I can to help you fix it :-)

@benhillis benhillis added the bug label Oct 31, 2016

@benhillis

This comment has been minimized.

Copy link
Member

commented Oct 31, 2016

@aseering This is definitely something that we should look into and get resolved. Sunil is our resident networking expert and I'll make sure he's aware that network hangs are still happening and reproducible.

@aseering

This comment has been minimized.

Copy link
Contributor Author

commented Oct 31, 2016

Thanks @benhillis ! Let me know if you're having trouble reproducing this in-house; I'm happy to play around / post more details / etc.

@sunilmut

This comment has been minimized.

Copy link
Member

commented Nov 1, 2016

@aseering Thanks, Adam for your persistence, which definitely keeps us on track. And, yes, I find it useful when people repost on an "old" issue that it is still reproducible on recent builds, because it "revives" the thread. I have opened a bug on our end to track this and will soon post my findings.

@sunilmut

This comment has been minimized.

Copy link
Member

commented Nov 2, 2016

@aseering - My initial investigation is pointing me to #1025. When both, the writer (http_examples) and the reader (curl) are running on WSL (and on the same device), the writer is much faster than the reader. This causes the send buffer to fill up fast, which results in EAGAIN being returned. At that point, the writer relies on EPOLL to know when the socket is again writable. On WSL (because of #1025) the EPOLL is not being set correctly and is returning that the socket is writeable even when the send buffer is full. Trusting the return value from EPOLL, when the writer tries to write to the socket, it again sees EAGAIN and gets confused and gives up. When the writer is moved to a different device and on native Ubuntu, all works fine. The fix for #1025 is a bit involved and so I am not able to immediately confirm the above. Should have something more on this soon.

@Manouchehri

This comment has been minimized.

Copy link
Contributor

commented Nov 5, 2016

Not sure if this is related, but on my WSL host I'm using a simple Go HTTP server to serve files (over >1GB each); after a few megabyte, the connection seems to die.

@aseering

This comment has been minimized.

Copy link
Contributor Author

commented Nov 19, 2016

@Manouchehri -- that actually sounds more like #610 to me. I imagine that ticket and this ticket are related somehow, though I don't know for sure.

@sunilmut

This comment has been minimized.

Copy link
Member

commented Dec 4, 2016

Just an update that this issue has been fixed in the dev branch and should soon hit the release branch. curl doesn't hang anymore, but it does return complaining that all the bytes were not transferred. I looked at the source of http_examples and it doesn't handle any errors (including EAGAIN) during send. With the slow reader on WSL, the send ends up returning EAGAIN soon and http_examples bails out. That's not related to the above issue, which should be fixed. The slow reader on WSL is a performance thing and something that we are aware of and do plan on spending resources looking at it sometime soon.
Many thanks @aseering for being persistent and helping us stay on track. I will also ping this thread again once the fix makes it to the release branch.

@Manouchehri

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2016

@aseering Thanks, my issue was indeed #610.

@spsDrop

This comment has been minimized.

Copy link

commented Dec 15, 2016

@sunilmut Do you have any idea what insider build this might land in?

@sunilmut

This comment has been minimized.

Copy link
Member

commented Dec 16, 2016

@Soljin - Unfortunately, no. The fix has not yet hit the release branch yet, but is moving up nicely. I will be sure to ping this thread when it hits the release build. Thanks for your patience.

@sunilmut

This comment has been minimized.

Copy link
Member

commented Jan 9, 2017

This should be fixed in 15002. Please validate and let us know if the issue persists. Thanks @aseering for staying on top of this.

@aseering

This comment has been minimized.

Copy link
Contributor Author

commented Jan 11, 2017

Quick update -- I'm using #15002 and have not seen this reproduce. Yay! But I have a collection of things that I'd like to test and I'm still working through them. I'll post an update when they've finished running.

@sunilmut

This comment has been minimized.

Copy link
Member

commented Jan 11, 2017

@aseering - Thanks for the validation. Good to know and waiting for the rest of the results.

@aseering

This comment has been minimized.

Copy link
Contributor Author

commented Jan 18, 2017

Sorry for the lengthy delay; I've been busy with some other things lately.

Anyway -- I've thrown a whole bunch of workloads at build 15007. (15002 had the issue where WSL always consumed a CPU core, and my test machine is only dual-core, so I upgraded right quick when that was fixed :-) ) I've found (and filed) a few other issues, but so far I have not seen a single recurrence of this hang. So, as far as I'm concerned, it's fixed! Feel free to close.

@sunilmut (and the rest of the WSL team) -- thanks! This particular fix is a huge improvement for me personally. In general, I always look forward to each new Insider build because there's always something new and useful in it :-)

@sunilmut

This comment has been minimized.

Copy link
Member

commented Jan 18, 2017

@aseering - Thanks very much for all the help in the various stages of this issue; from filing, to diagnosis, for patience, to resolution and finally fixing and validating :). We are definitely glad that a core issue is fixed. I will keep this issue around for some more days and then close it out. Thanks again!

@RaphaelVasconcelos

This comment has been minimized.

Copy link

commented Dec 28, 2018

Is this problem solved?

WSL Ubuntu 18.04
Version - 1804.2018.817.0

When running "pub global active webdev" (Dart Server command) in WSL, i get this error:

SLVR: Version solving took 0:04:01.201544 seconds. | Tried 1 solutions. FINE: Resolving dependencies finished (4:01.207s). ERR : Connection closed while receiving data FINE: Exception type: ClientException FINE: package:pub/src/source/hosted.dart 341:7 BoundHostedSource._throwFriendlyError | package:pub/src/source/hosted.dart 142:7 BoundHostedSource.doGetVersions | ===== asynchronous gap =========================== | dart:async _AsyncAwaitCompleter.completeError | package:pub/src/source/hosted.dart BoundHostedSource.doGetVersions | ===== asynchronous gap =========================== | dart:async _asyncErrorWrapperHelper | package:pub/src/source/hosted.dart BoundHostedSource.doGetVersions | package:pub/src/source.dart 167:12 BoundSource.getVersions | package:pub/src/solver/package_lister.dart 76:44 PackageLister._versions.<fn>.<fn> | package:pub/src/http.dart 271:51 withDependencyType | package:pub/src/solver/package_lister.dart 75:33 PackageLister._versions.<fn> | ===== asynchronous gap =========================== | dart:async _asyncThenWrapperHelper | package:pub/src/utils.dart minByAsync | package:pub/src/solver/version_solver.dart 350:25 VersionSolver._choosePackageVersion | ===== asynchronous gap =========================== | dart:async _asyncThenWrapperHelper | package:pub/src/solver/version_solver.dart VersionSolver.solve | package:pub/src/solver.dart 35:10 resolveVersions.<fn> | package:pub/src/log.dart 378:18 progress | package:pub/src/solver.dart 32:10 resolveVersions | package:pub/src/global_packages.dart 178:22 GlobalPackages._installInCache

On Ubuntu 18.04 is fine!

Thanks!

More details about this issue pub get failed on windows 10 linux subsystem#27554

@therealkenc

This comment has been minimized.

Copy link
Collaborator

commented Dec 28, 2018

Is this problem solved?

Yes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.