Panic on Resize

[Dominik Schulz]

Hi,

we get this issue when resizing some user-supplied pictures.

And no, unfortunately I can't provide any sample pics. I'll try to get one.

goroutine 5456 [running]:
panic(0xc34040, 0xc42000c0c0)
        /usr/local/go/src/runtime/panic.go:500 +0x1a1
github.com/nfnt/resize.resizeRGBA(0xc4203e4c40, 0xc4203e58c0, 0x0, 0xc422c18000, 0x1944, 0x1944, 0x
        github.com/nfnt/resize/converter.go:119 +0x44d
github.com/nfnt/resize.Resize.func2(0xc420610140, 0xc4203e4c40, 0xc4203e58c0, 0x0, 0xc4205900a0, 0x
        github.com/nfnt/resize/resize.go:130 +0xc5
created by github.com/nfnt/resize.Resize
       github.com/nfnt/resize/resize.go:131 +0x345b

[Alex Nichol]

Could you post the actual panic message in addition to the backtrace you supplied?

[Dominik Schulz]

Sorry, forgot to include that one. It was an panic: runtime error: index out of range.

Besides the fact that this should not happen, it's also impossible (?) to catch with recover since the Code is running in it's own goroutine.

[Jan Schlicht]

Hard to say without a sample, because (in theory) this shouldn't happen. Unfortunately it's not possible to avoid this in code, by e.g. using for range, without losing a lot of performance.

[Dominik Schulz]

We are trying to isolate some good test cases, but it's a lot of work given the number of candidate images we have. Will report back if we are able to narrow this down.

For our use case it would be preferable to sacrifice some performance for reliability.

[Alex Nichol]

I recently ran into this bug myself. It was caused because I was resizing 0x0 images with bilinear interpolation.

[Dominik Schulz]

We found some way to isolate some useable testcases, but I'm really busy the next few weeks. I'll try to provide some samples anytime soon.