Hugo Server issue with multilingual mode versions > 0.55.6

Hi All,

I am having an issue with a large hugo site of mine. It has many content files and over 5 languages. I am currently using Hugo version 0.55.6. My goal is to upgrade hugo to the latest version 0.59.0. However, when upgrading to any version greater than 0.55.6 and running the hugo server command, I get this issue:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x4550bee]
goroutine 1818 [running]:
github.com/gohugoio/hugo/hugofs.(*fileInfoMeta).IsDir(0xc00d054a80, 0xc0007480a0)
        <autogenerated>:1 +0x2e
github.com/gohugoio/hugo/hugofs.(*FilterFs).LstatIfPossible(0xc0007480c0, 0xc024d4cb27, 0x4, 0x400e4fc, 0xfded8f0, 0x13f, 0xc0007e39e0, 0x54d92a0)
        /private/tmp/hugo-20191021-17314-9w2g7c/hugo-0.59.0/src/github.com/gohugoio/hugo/hugofs/filter_fs.go:152 +0x92
github.com/gohugoio/hugo/hugofs.(*FilterFs).Stat(0xc0007480c0, 0xc024d4cb27, 0x4, 0xc00cf6a250, 0x1, 0x203003, 0x203003)
        /private/tmp/hugo-20191021-17314-9w2g7c/hugo-0.59.0/src/github.com/gohugoio/hugo/hugofs/filter_fs.go:208 +0x3f
github.com/gohugoio/hugo/hugolib.(*pagesCollector).collectDir(0xc028ce8ff0, 0xc024d4cb27, 0x4, 0xc01a55ec01, 0x0, 0xc024d4cb27, 0x4)
        /private/tmp/hugo-20191021-17314-9w2g7c/hugo-0.59.0/src/github.com/gohugoio/hugo/hugolib/pages_capture.go:151 +0x66
github.com/gohugoio/hugo/hugolib.(*pagesCollector).Collect(0xc028ce8ff0, 0xc028ce8ff0, 0xc0007480c0)
        /private/tmp/hugo-20191021-17314-9w2g7c/hugo-0.59.0/src/github.com/gohugoio/hugo/hugolib/pages_capture.go:126 +0x2de
github.com/gohugoio/hugo/hugolib.(*Site).readAndProcessContent(0xc0004c1880, 0xc019f8f1e0, 0x1, 0x1, 0x1, 0x1)
        /private/tmp/hugo-20191021-17314-9w2g7c/hugo-0.59.0/src/github.com/gohugoio/hugo/hugolib/site.go:1249 +0x187
github.com/gohugoio/hugo/hugolib.(*Site).processPartial(0xc0004c1880, 0xc02ecbc0c0, 0xc01a55f6c8, 0xc008f6aa80, 0x1, 0x1, 0xc01f0a44f8, 0x18)
        /private/tmp/hugo-20191021-17314-9w2g7c/hugo-0.59.0/src/github.com/gohugoio/hugo/hugolib/site.go:1050 +0xdca
github.com/gohugoio/hugo/hugolib.(*HugoSites).process(0xc000708780, 0xc02ecbc0c0, 0xc01a55f6c8, 0xc008f6a940, 0x1, 0x1, 0x40303ea, 0x406f701)
        /private/tmp/hugo-20191021-17314-9w2g7c/hugo-0.59.0/src/github.com/gohugoio/hugo/hugolib/hugo_sites_build.go:225 +0x99
github.com/gohugoio/hugo/hugolib.(*HugoSites).Build.func2.2()
        /private/tmp/hugo-20191021-17314-9w2g7c/hugo-0.59.0/src/github.com/gohugoio/hugo/hugolib/hugo_sites_build.go:103 +0x64
runtime/trace.WithRegion(0x5a8b180, 0xc027317530, 0x56f8dd5, 0x7, 0xc01a55f6f0)
        /usr/local/Cellar/go/1.13.3/libexec/src/runtime/trace/annotation.go:137 +0x115
github.com/gohugoio/hugo/hugolib.(*HugoSites).Build.func2(0x40303ea, 0x1)
        /private/tmp/hugo-20191021-17314-9w2g7c/hugo-0.59.0/src/github.com/gohugoio/hugo/hugolib/hugo_sites_build.go:105 +0x162
github.com/gohugoio/hugo/hugolib.(*HugoSites).Build.func3()
        /private/tmp/hugo-20191021-17314-9w2g7c/hugo-0.59.0/src/github.com/gohugoio/hugo/hugolib/hugo_sites_build.go:122 +0x2f
runtime/trace.WithRegion(0x5a8b180, 0xc027317530, 0x56f8d73, 0x7, 0xc01a55f920)
        /usr/local/Cellar/go/1.13.3/libexec/src/runtime/trace/annotation.go:137 +0x115
github.com/gohugoio/hugo/hugolib.(*HugoSites).Build(0xc000708780, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc027317500, 0xc008f6a940, 0x1, ...)
        /private/tmp/hugo-20191021-17314-9w2g7c/hugo-0.59.0/src/github.com/gohugoio/hugo/hugolib/hugo_sites_build.go:124 +0x80b
github.com/gohugoio/hugo/commands.(*commandeer).rebuildSites(0xc0006b5110, 0xc008f6a940, 0x1, 0x1, 0x0, 0x0)
        /private/tmp/hugo-20191021-17314-9w2g7c/hugo-0.59.0/src/github.com/gohugoio/hugo/commands/hugo.go:738 +0x3e8
github.com/gohugoio/hugo/commands.(*commandeer).handleEvents(0xc0006b5110, 0xc026e97f80, 0xc024bce060, 0xc01f0a44e0, 0x2, 0x2, 0xc01545ee70)
        /private/tmp/hugo-20191021-17314-9w2g7c/hugo-0.59.0/src/github.com/gohugoio/hugo/commands/hugo.go:1095 +0x710
github.com/gohugoio/hugo/commands.(*commandeer).newWatcher.func1(0xc026e97f80, 0xc0006b5110, 0xc024bce060, 0xc01545ee70)
        /private/tmp/hugo-20191021-17314-9w2g7c/hugo-0.59.0/src/github.com/gohugoio/hugo/commands/hugo.go:842 +0x1d8
created by github.com/gohugoio/hugo/commands.(*commandeer).newWatcher
        /private/tmp/hugo-20191021-17314-9w2g7c/hugo-0.59.0/src/github.com/gohugoio/hugo/commands/hugo.go:838 +0x293

To test this error on smaller scale, I created a new hugo site with the quickstart guide. The repo is here: https://github.com/zbayoff/quickstart

I tested with 3 different language directories: en, fr, and es. I created a test post in 2 of these directories and tested with both version 0.55.6 and greater. The reason I’m not adding the post to all of the directories is because that’s how it is in my larger hugo site. Not all the content has been translated so only the en blog posts and some of the es posts exist.

The site builds and reloads fine with version 0.55.6, but greater than this version, and I get the error above.

I found this issue Runtime error (invalid memory address or nil pointer dereference) while running the server
where someone experienced a similar problem, if an md file is not present in all of the language directories, then hugo server will throw an error.

Please see the test repo above to recreate the issue. Try hugo version 0.55.6, there should be no error. Try hugo version greater than 0.55.6, there should be an error. Then copy the test blog post to content/es, the error should go away.

Any help would be appreciated.

Thank you.

I can confirm this error. Tested with your repo and unfortunately with mine.

In my repo, the problem occurs after this commit, when a subdirectory of the en and the fr directories in content have exactly the same name.

After changing the name in one of the language directories, the error doesn’t occur.

Should I open a bug?

EDIT: after reading above mentionned post, I had the idea to create empty directories with same names in the third language dir de, and to my big surprise, the error doesn’t occur anymore.

Thanks for reporting, and esp. for the test site which makes fixing this so much easier.

I create this issue to track it:

1 Like

This should be fixed in 0.59.1. An obvious but curious bug.

1 Like