On Fri, Feb 23, 2018 at 1:19 AM, Michael Andersen wrote:
>
> Ok I found the problem. A tight loop was indeed preventing the garbage
> collector from proceeding, and then the GC was stopping everything else. The
> loop contained atomic.LoadUint64 and atomic.CompareAndSwapUint64, but
> neither of th
Ok I found the problem. A tight loop was indeed preventing the garbage
collector from proceeding, and then the GC was stopping everything else.
The loop contained atomic.LoadUint64 and atomic.CompareAndSwapUint64, but
neither of those seem to qualify as preemption points. Fixing that loop
fixes eve
I have found that GODEBUG=schedtrace still prints when the program is
frozen but I cannot find much documentation on deciphering its output. The
full output is here:
https://gist.github.com/immesys/7f213c63c54ce60ba72d1cbc9ffcc4cb but here
are the first few lines. It looks like this is garbage coll
Hi
Thanks for your suggestions. This freeze happens to coincide with a larger
number of cgo calls which in turn most likely do blocking read/write from
sockets. How are those treated by the scheduler?
I am not doing anything FUSE related, nor do I have assembly code. The only
"interesting" stuff
On Thu, Feb 22, 2018 at 5:48 PM, Michael Andersen wrote:
>
> I have a complex program that when under load will very reproducibly freeze
> every goroutine simultaneously. It then makes no progress at all, even if
> left for hours. I'm posting here because I don't know of anything that can
> cause
Hi all
I have a complex program that when under load will very reproducibly freeze
every goroutine simultaneously. It then makes no progress at all, even if
left for hours. I'm posting here because I don't know of anything that can
cause this behavior so I don't even know where to begin debuggi
