New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Panic on batch-resizing images during livereload #2625

Closed
brasilikum opened this Issue Oct 24, 2016 · 6 comments

Comments

Projects
None yet
6 participants
@brasilikum
Contributor

brasilikum commented Oct 24, 2016

The following panic occurred while I was batch resizing images with sips -Z 1280 *.png with hugo serve -v running on OSX 10.12.1 Beta (16B2553a).

Syncing /images/video_thumb_play.png to /
panic: close of closed channel

goroutine 163 [running]:
panic(0x64cdc0, 0xc4200b0d40)
    /usr/local/Cellar/go/1.7.1/libexec/src/runtime/panic.go:500 +0x1a1
github.com/spf13/hugo/livereload.(*hub).run(0xa46880)
    /private/tmp/hugo-20161007-85797-vy50e9/hugo-0.17/src/github.com/spf13/hugo/livereload/hub.go:44 +0x1d9
created by github.com/spf13/hugo/livereload.Initialize
    /private/tmp/hugo-20161007-85797-vy50e9/hugo-0.17/src/github.com/spf13/hugo/livereload/livereload.go:64 +0x41

@bep bep added the Bug label Oct 24, 2016

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Oct 24, 2016

Member

This looks rare -- and the code in question seems to have been borrowed from the Gorilla mux project.

Member

bep commented Oct 24, 2016

This looks rare -- and the code in question seems to have been borrowed from the Gorilla mux project.

@moorereason

This comment has been minimized.

Show comment
Hide comment
@moorereason

moorereason Dec 28, 2016

Contributor

The underlying problem appears to be that we have a race condition between two code paths that can close the websocket send channel: hub.go#L44 and hub.go#L51.

I don't think we copied this from the gorilla project, or at least I can't find it anywhere.

Contributor

moorereason commented Dec 28, 2016

The underlying problem appears to be that we have a race condition between two code paths that can close the websocket send channel: hub.go#L44 and hub.go#L51.

I don't think we copied this from the gorilla project, or at least I can't find it anywhere.

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Dec 28, 2016

Member

I don't think we copied this from the gorilla project, or at least I can't find it anywhere.

Let's assume I didn't make that up, but it doesn't matter.

Member

bep commented Dec 28, 2016

I don't think we copied this from the gorilla project, or at least I can't find it anywhere.

Let's assume I didn't make that up, but it doesn't matter.

@gwatts

This comment has been minimized.

Show comment
Hide comment
@gwatts

gwatts Jan 17, 2017

As an extra datapoint I hit this same panic last night while a large number of files were being updated by a build program

gwatts commented Jan 17, 2017

As an extra datapoint I hit this same panic last night while a large number of files were being updated by a build program

@d-led

This comment has been minimized.

Show comment
Hide comment
@d-led

d-led Mar 3, 2017

have been getting these crashes (same stack trace) frequently today, also upon syncing a large number of files

d-led commented Mar 3, 2017

have been getting these crashes (same stack trace) frequently today, also upon syncing a large number of files

@philc

This comment has been minimized.

Show comment
Hide comment
@philc

philc Apr 29, 2017

I use hugo often and don't regularly experience crashes, but today began working on a big file and I discovered that I can reliably crash hugo (e.g. every 5s) with the stack trace in this issue by having a large file open in a browser and editing and saving it frequently. The size is 5284765 bytes of generated HTML in my case. I tried trimming this file to see if there's a specific file size the triggers the crash, but I can't reliably zero in on a semi-precise threshold.

It would be great to fix the race condition. It's very annoying, and not rare in my case.

philc commented Apr 29, 2017

I use hugo often and don't regularly experience crashes, but today began working on a big file and I discovered that I can reliably crash hugo (e.g. every 5s) with the stack trace in this issue by having a large file open in a browser and editing and saving it frequently. The size is 5284765 bytes of generated HTML in my case. I tried trimming this file to see if there's a specific file size the triggers the crash, but I can't reliably zero in on a semi-precise threshold.

It would be great to fix the race condition. It's very annoying, and not rare in my case.

@bep bep self-assigned this Apr 29, 2017

@bep bep added this to the v0.21 milestone Apr 29, 2017

@bep bep closed this in 355736e Apr 29, 2017

@ghost ghost referenced this issue May 22, 2017

Open

spf13/hugo v0.21 released #10

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment