May be a case where hackage-security client uses 100% CPU and does not terminate

[mgsloan]

See this stack issue: commercialhaskell/stack#3572

Assuming it's from a relatively recent version of stack, this is likely a bug in hackage-security.

[hvr]

Is there any chance to get a reasonably reliable repro-case? It's going to be quite difficult to track this down without additional information; and from the logging output in that ticket it's not clear to me which entry-point into hackage-security got stuck.

[alexanderkjeldaas]

how can I give useful log-output. I have this as a docker image so it's fairly easy to repro.

[hvr]

@alexanderkjeldaas That sounds promising! I'm not familiar with Stack, but I'd try turning up verbosity to the max in the hopes to get as much log-messages from hackage-security (as well as from the transport layer; if there doesn't appear to be enough logging for the transport layer, tcpdump would be worth a try) emitted as possible. If this also doesn't give enough hints, good old printf-style debugging might be in order...; but let's cross that bridge when we come to it...

[mgsloan]

I do not think that verbosity is likely to help much. Stack does very little between Updating package index ... and running code from hackage security. In all codepaths after hackage security returns, there are further messages.

However, it may be helpful to know that -v --cabal-verbose is the max verbosity (verbose stack logs + verbose cabal logs). This will not have an effect on the output of hackage security, because it doesn't seem to have verbosity settings. The function we are passing in for it to use for output (7th argument of withRepossitory), is a function that always outputs regardless of verbosity level.