Potential deadlock in GroupByParam/ByParam

[sparksp]

I recently took a huge leap from v0.85.0 to v0.112.3 (and also tried v0.111.3) and have found my build it hanging more often than not. When it succeeds it builds fast, when it hangs it seems to do so forever. I have this issue locally on my mac, and also on Netlify. I have now wrapped my build script with until timeout -s SIGABRT 5m hugo ; do : ; done so that it is forced to retry after 5 minutes until it succeeds, and provides the useful go dump when it fails. I have a recent Netlify build log here, where it took 3 attempts to build - search for "Start building sites" for the top of each attempt. The site code is public at sparksp/lt-osp.

Hopefully someone is able to see something useful in the go dump that might lead to either an issue with my site, or an issue with hugo.

Version

hugo v0.112.3-ba6f74e40420d76f15fc8c2358be90f7aca98e0e+extended linux/amd64 BuildDate=2023-05-24T14:42:50Z VendorInfo=gohugoio

Does this issue reproduce with the latest release?

Yes.

[jmooring]

I can reproduce with v0.97.0 and later. The problem is here:

https://github.com/sparksp/lt-osp/blob/rules-v4/themes/lt-osp/layouts/partials/lists/term/ladder.html

If I comment out the contents, the build completes quickly.

To simplify the problem, replace the contents with:

{{ range .Pages.ByWeight.GroupByParam "tier" }}
  {{ range .Pages.ByParam "ladder_group" }}
    {{ warnf "%[1]v (%[1]T)" .Params.ladder_group }}
  {{ end }}
{{ end }}

Then run while true; do hugo; done and wait for it to hang.

Then change it to this (remove the .ByParam method):

{{ range .Pages.ByWeight.GroupByParam "tier" }}
  {{ range .Pages }}
    {{ warnf "%[1]v (%[1]T)" .Params.ladder_group }}
  {{ end }}
{{ end }}

No problems.

We made some changes to .ByParam in v0.97.0 (see #9772). If you look at values displayed by the warnf function above, you will see that is a mix of strings ("1", "2", "3", "right") and nil.

---

You can use v0.112.x if you reduce the number of workers to 1.

while true; do HUGO_NUMWORKERMULTIPLIER=1 hugo; done

[sparksp]

Thank-you for looking at this so quickly, and having a work around! Do you know if this is something likely to be resolved in Hugo at some point? I don't want to put much effort into trying to change my logic (if I can), or adding ladder_groups to all my skill pages. If it might be resolved in the near future then I can live with the worker reduction. It does also seem like something that may trip other people up in the future. The documentation does imply that it's okay to use with mixed content

If the parameter is not found at all in some entries, those entries will appear together at the end of the ordering.

[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.