crash in resize
kjk opened this issue · comments
Unfortunately I don't have access to image that caused the crash and don't know what was its size and what was the destination size. It could be related to some boundary conditions (very small source or very small destination size).
But this happened using the latest resize (ccddecd):
panic: runtime error: slice bounds out of range
goroutine 574 [running]:
runtime.panic(0x914ac0, 0xc524af)
/usr/local/Cellar/go/1.3/libexec/src/pkg/runtime/panic.c:279 +0xf5
github.com/nfnt/resize.resizeRGBA(0xc208256440, 0xc208256700, 0x3fff7b03531dec0d, 0xc20808a500, 0x268, 0x268, 0xc20808aa00, 0x9a, 0x9a, 0x4)
/var/folders/9t/62vbwdb93rg3tpvsy6y30tzh0000gn/T/godep/rev/cc/ddecd1bf0b15e36e2ffcfdef7c6832eaa0dbf6/src/github.com/nfnt/resize/converter.go:98 +0x5b3
github.com/nfnt/resize.func·001()
/var/folders/9t/62vbwdb93rg3tpvsy6y30tzh0000gn/T/godep/rev/cc/ddecd1bf0b15e36e2ffcfdef7c6832eaa0dbf6/src/github.com/nfnt/resize/resize.go:112 +0xcb
created by github.com/nfnt/resize.Resize
/var/folders/9t/62vbwdb93rg3tpvsy6y30tzh0000gn/T/godep/rev/cc/ddecd1bf0b15e36e2ffcfdef7c6832eaa0dbf6/src/github.com/nfnt/resize/resize.go:113 +0x27bc
This corresponds to the crash at the last line of this:
func resizeRGBA(in *image.RGBA, out *image.RGBA, scale float64, coeffs []int16, offset []int, filterLength int) {
oldBounds := in.Bounds()
newBounds := out.Bounds()
minX := oldBounds.Min.X * 4
maxX := (oldBounds.Max.X - oldBounds.Min.X - 1) * 4
for x := newBounds.Min.X; x < newBounds.Max.X; x++ {
row := in.Pix[(x-oldBounds.Min.Y)*in.Stride:]
This is on a 24-core amd64 ubuntu 12.4 box, go 1.3.
On a related note: it would be good to have an option to disable internal nfnt threading (i.e. make it do the resize using a single, current goroutine) so that it's possible to catch and recover from crashes in nfnt with recover(). Imagine a server application that does image resizing - if a crash in nfnt happens on some random goroutine, it'll crash the whole server. If it happens on current goroutine, I can write a wrapper that will recover() from the panic().
I'm having the same problem in converter.go at line 282. Looks like the same crash, but in resizeYCbCr function instead of the RGBA equivalent.
I do actually have access to the image that crashed it...
I was requesting a resize with width: 0 and height: 1024... so ideally preserving the aspect ratio...
I'm also seeing 'out of range' errors in resize. I'll do some digging here to see if I can narrow down what happened.
I'm on OSX. I'm resizing gif, pngs, and jpgs normally. The only issue I've had is resizing jpgs.
If I cd to the GOPATH/nfnt/resize/ directory and checkout the following commit, my resize.Resize() function starts working.
➜ resize: git checkout bdfbbead1345d809ac818ffd1a66ace065aaf821
gitPrevious HEAD position was 016a61c... Optimize data-locality for a huge increase in processing speed.
HEAD is now at bdfbbea... Merge branch 'anisus-master' Fixes #14, regression from 494d8de4e58cee6b5b9072a4a1c97e8dc9863a16
➜ resize git:(bdfbbea) @henryclay Can you revert to that point and see if that changes your results?
Also, I updated resize yesterday. I don't know how far behind I was unfortunately.
@jfolkins Checked out at that hash, and it works. So it's definitely something that happened in the interim.
If I go* one commit newer, it crashes. Same result for you @henryclay?
➜ resize git:(bdfbbea) git checkout 016a61c
gitPrevious HEAD position was bdfbbea... Merge branch 'anisus-master' Fixes #14, regression from 494d8de
HEAD is now at 016a61c... Optimize data-locality for a huge increase in processing speed.
➜ resize git:(016a61c)
*edit: s/got/go/
@henryclay using the latest version ccddecd and Go 1.3 I was unable to recreate the panic with the picture you supplied.
I tested each interpolation function and each width from 100-1400 with height set to 0, and did the reverse for testing height. I also tested a smaller range (1000-1200), but with the cpu count set from 1-1000. I ran tests on a 2012 MBP (OS X 10.9.4) and a Hackintosh running OS X 10.9.3 with an intel i5-3570k.
The panic at line 282 in converter.go is odd in that the value is bound checked, and ycc's SubImage method passes the image pkg's tests for similarly structured in memory images. Without a reproducible error it will be hard to figure out what is causing the error here.
@kjk I was not able to reproduce the panic you described, but that slice index should be bound checked and the converter functions changed to return an error (via a channel).
I will take some time this evening to work on said changes and add ability to control resizes threading. I will most likely submit a pull request to @nfnt sometime in the next day or two.
Hi, I'm super busy right now. Will try to look into it in the next days. Probably tomorrow. @henryclay: I did a quick check with your image and couldn't reproduce the panic. I'm using OS X 10.9.4 but will check it with Linux as well.
@nfnt No worries. There's no rush. I'm using the older version that is working just fine (for the time being; the hash as supplied by @jfolkins).
That image will cause the problem reliably for me, but I'm in google app engine, so debugging is pretty frustrating. And the environment is pretty different. I'm suspicious of googles image library, or my utilization of it.
Maybe because I'm returning a subimage of the original and then passing it to resize? According to documentation: "SubImage returns an image representing the portion of the image p visible through r. The returned value shares pixels with the original image"
The image I shared above is an encode to jpeg of the image that, in memory, is causing issues... so it's entirely possible it's a red-herring (ie. encode solved the issue). I was hoping it was somehow related to the size... since it's only some images I have issues with. But clearly not.
Let me know if there's other info I could give you to help out.
Thanks, for finding that. I just fixed the error and made a pull request.
Sorry, I deleted that comment after I found out that it's even more:
img := image.NewRGBA(image.Rect(20, 10, 200, 99))
out := Resize(80, 80, img, NearestNeighbor)will panic as well. So it's not related to image.YCbCr but to the access of the input image data in general. It's a regression from 016a61c, the lines row := in.Pix[(x-oldBounds.Min.Y)*in.Stride:] are to blame. x will always start at zero, because the output image is constructed this way, but if using subimage, oldBounds.Min.Y will be >0. Accessing in.Pix with an index <0 causes the panic.
Thanks to you all! This thread is a very nice example of what I appreciate about OSS.
Sorry accidentally deleted my last comment while trying to edit it, but unlike my now deleted suggestion the following does work.
In convert.go and nearest.go setting oldBounds to image.Rect(0, 0, in.Rect.Dx(), in.Rect.Dy()) seems to work, and does not change the rectangle of the image being passed to Resize.
oldBounds := image.Rect(0, 0, in.Rect.Dx(), in.Rect.Dy())
newBounds := out.Bounds()
I added the above changes to my master branch, and they are included in my pull request (fixing YCbCr/YCC errors) from earlier.
@nfnt thanks for tracking down the root cause of panic!
@charlievieth: Thanks for the pull request. That fixes the bug. It's been merged in 03982f6. I've added a simple test case to (hopefully) detect the panic in future changes.
I was trying out a solution independently that tried to handle non-zero min values of the input bounds. Your fix of setting oldBounds to min values of zero is much simpler, much appreciated!
Thanks, I¹m happy that I was able to help out.
From: jst notifications@github.com
Reply-To: nfnt/resize
<reply+i-39859754-0eaaac4be05787b91961d41f7ff9588829e308ff-4875142@reply.git
hub.com>
Date: Wednesday, August 13, 2014 at 2:18 PM
To: nfnt/resize resize@noreply.github.com
Cc: Charles Vieth charlie.vieth@gmail.com
Subject: Re: [resize] crash in resize (#17)
@charlievieth https://github.com/charlievieth : Thanks for the pull
request. That fixes the bug. It's been merged in 03982f6
<03982f6
738> . I've added a simple test case to (hopefully) detect the panic in
future changes.
I was trying out a solution independently that tried to handle non-zero min
values of the input bounds. Your fix of setting oldBounds to min values of
zero is much simpler, much appreciated!
‹
Reply to this email directly or view it on GitHub
#17 (comment) .
Bad news bears. So that fixed the panic... but I'm not sure it actually works as intended. I've had to go back to that old hash again, but check this out:
Resized:
To:
I'm using a subimage in the center... to attain a 3x4 ratio. I'm guessing the code that resizes still has some bounds issues...
Here's some debug output statements that I think make it more clear what I'm doing here:
2014/08/16 00:30:27 INFO: got image with format: jpeg size: 1280, 800
2014/08/16 00:30:27 INFO: cropping image using bounds: 0.265625, 0.000000, 0.734375, 1.000000
2014/08/16 00:30:27 INFO: sub image using bounds: 340, 0, 940, 800
2014/08/16 00:30:27 INFO: cropped image to size: 600, 800
2014/08/16 00:30:27 INFO: resize image to size: 768, 1024
Again, checking out bdfbbea works fine... so I'll stay there for now.
NOOOOO! I thought this new bug wasn't affecting me. Turns out it is.
It happens when I apply cropping too.
Dang. Yeah reverting to commit bdfbbea appears to work.
I¹m currently on vacation, but will look into this on Thursday.
From: Jared Folkins notifications@github.com
Reply-To: nfnt/resize
<reply+i-39859754-0eaaac4be05787b91961d41f7ff9588829e308ff-4875142@reply.git
hub.com>
Date: Tuesday, August 19, 2014 at 11:23 PM
To: nfnt/resize resize@noreply.github.com
Cc: Charles Vieth charlie.vieth@gmail.com
Subject: Re: [resize] crash in resize (#17)
Dang. Yeah reverting to commit bdfbbea
<bdfbbea
821> appears to work.
‹
Reply to this email directly or view it on GitHub
#17 (comment) .
Poor Natalie! It should be fixed now. The fix currently does not support concurrent calculation. That will be fixed in another commit. Anyways, it should be faster than in bdfbbea. I appreciate some feedback whether it works for you guys.
Parallel should now work as well.
Yup it works. I have longer running background jobs that create multiple cropped images and then store them in a cache. As a small bench mark I'm seeing jobs that took 7 seconds drop down to around 4.5. These are computationally intensive tasks.
Thanks!
Looking good here. Thanks a lot!