hugo serve -D hangs at "Start building sites" when serving locally

[Lyoness]

What version of Hugo are you using (hugo version)?

$ hugo version
hugo v0.108.0+extended darwin/arm64 BuildDate=unknown

Does this issue reproduce with the latest release?

at latest.

When running hugo serve -D the process hangs at:

Start building sites …
hugo v0.108.0+extended darwin/arm64 BuildDate=unknown

This starts to throttle my CPU:

$ps aux | grep -i hugo
carmen           27950  98.4  0.7 409417616 115232 s000  R+    1:06PM   3:48.40 hugo serve -D

Coredump here: https://gist.github.com/Lyoness/c2a4f259e652b60239892b08f07c08df

Thank you, happy to add any more context if needed.

[Lyoness]

Not sure if #8166 is similar, but it hangs at Start building sites …

[bep]

My best guess is an infinite recursion in some partial, which I guess can happen. Does it happen only when running the server? Is the source somehow available for me to test/look at?

[anne-usmedia]

I'm having the same issue, but with v0.110.0. Sometimes it hangs and sometimes it works, seems to be random. And when I get the project up and running it always hangs again when I change something in the scss.

Co-workers working on a linux computer do not have any issues, my fellow Macbook users are having the same problems as me.

repo: https://github.com/cue-lang/cuelang.org/tree/alpha

[jmooring]

@anne-usmedia Whenever I hear about Mac vs Linux behavior, and the project uses Hugo Modules, the first thing that comes to mind is volatility of the cache location.

See https://discourse.gohugo.io/t/37837/6

This may not address the problem that you are experiencing, but it’s good starting point.

[myitcv]

I can also repro this. Raised golang/go#58814 on the Go side. The stack trace in that issue (like the one above) clearly shows things blocked on the cgo call to libsass. All other goroutines are blocked (I'm assuming there is some global lock for cgo calls).

@jmooring

Whenever I hear about Mac vs Linux behavior, and the project uses Hugo Modules, the first thing that comes to mind is volatility of the cache location.

We are not using Hugo modules AFAIK.

[jmooring]

@myitcv

We are not using Hugo modules AFAIK.

Understood. I saw the go.mod and didn't look inside.

[myitcv]

I've tracked down the problem here. Per golang/go#58814 (comment), this is a Go problem that was fixed in golang/go@7d3a5a5. That commit is present in go1.20.

I notice that https://github.com/gohugoio/hugo/releases/tag/v0.111.0 has just been released. That was built using go1.20. So anyone seeing this problem should find that it is fixed by v0.111.0.

[myitcv]

@Lyoness - I'd suggest this issue can be closed now per #10565 (comment)

[sftim]

I can reproduce this with some consistency trying to build the Kubernetes docs locally. Out of 5 attempts it's very likely that at least one will freeze (stop making progress).

[myitcv]

@sftim did you see #10565 (comment)?

@bep I think this can be closed so long as at least go1.20 is used to build hugo versions.

[sftim]

I'm happy to see this closed as I can't reproduce the symptoms locally any more (we - Kubernetes docs - switched to building the development container with Golang 1.20)

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.