Segmentation fault

[da2x]

Segmentation fault on almost all images that are downscaled with e.g, Vips::Image.thumbnail('source.png', 1920, height: 1080, **{crop: 'centre', size: :down}). Some images work if I remove the height parameter, but there’s still a large number that fail. All the same images worked just fine on this system two weeks ago.

I tried downgrading from ruby-vips 2.0.17 (released today) to ruby-vips 2.0.16, but it still fails. I’m really not sure what else has changed on my environment over the holidays.

/rubygems/gems/ruby-vips-2.0.17/lib/vips/operation.rb:187: [BUG] Segmentation fault at 0x0000000000000000
ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-linux]

-- Control frame information -----------------------------------------------
c:0040 p:---- s:0234 e:000233 CFUNC  :vips_cache_operation_build
c:0039 p:0012 s:0229 e:000228 METHOD /rubygems/gems/ruby-vips-2.0.17/lib/vips/operation.rb:187
c:0038 p:0357 s:0224 e:000223 METHOD /rubygems/gems/ruby-vips-2.0.17/lib/vips/operation.rb:402
c:0037 p:0023 s:0207 e:000206 METHOD /rubygems/gems/ruby-vips-2.0.17/lib/vips/image.rb:216

• ruby-vips 2.0.17 (rubygems)
• ruby 2.7.2 (fedora 33 repo)
• vips 8.9.2 (fedora 33 repo)

[jcupitt]

Oh dear, that's very bad.

Could it be a change in the ffi gem? That's the only other thing that ruby-vips depends on.

[jcupitt]

I made a simple dockerfile which runs ruby-vips on fedora33:

https://github.com/jcupitt/docker-builds/tree/master/ruby-vips-fedora33

It seems to work for me. I see:

$ docker run -it --rm -v $PWD:/data ruby-vips-fedora33 ./thumb.rb

And it makes a thumbnail.

Do you have an image which it fails for?

You could also write your thumbnail line as:

x = Vips::Image.thumbnail("Gugg_coloured.jpg", 100, height: 100, crop: :centre, size: :down)

I expect you know.

[shllg]

I don't even get a segmentation fault but the application will just freeze. As @da2x described, everything worked fine some week before. Using ActiveStorage to store/resize image. After running with a debugger, I found that it'll break here:

ruby-vips-2.1.3/lib/vips/operation.rb

# line 211
op = Vips.vips_cache_operation_build self

It did not work for

• Ruby 2.7.3, 2.7.4, 3.0.2
• mac os x vips 8.11.4 via homebrew

I tested several ffi and ruby-vips versions (and combinations).

The last command is always before it freezes:

[81, 90] in /.../versions/3.0.2/lib/ruby/gems/3.0.0/gems/ffi-1.15.4/lib/ffi/struct.rb
   81:     end
   82:
   83:     # Get {Pointer} to struct content.
   84:     # @return [AbstractMemory]
   85:     def to_ptr
=> 86:       pointer
   87:     end
   88:
   89:     # Get struct size
   90:     # @return [Numeric]

It might have something to do with vips on mac os. Still I wanted to give an update here.

[jcupitt]

Thank you for the report, I'll see if I can reproduce this on my mac.

[jcupitt]

I updated everything (macos, dev tools, brew, took a while, ouch) and it seems to work for me. I see:

13:23 $ irb --version
irb 1.3.5 (2021-04-03)
✔ ~/pics 
13:25 $ which irb
/usr/local/opt/ruby/bin/irb
✔ ~/pics 
13:25 $ ruby --version
ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-darwin19]
✔ ~/pics 
13:25 $ which gem
/usr/local/opt/ruby/bin/gem
✔ ~/pics 
13:25 $ gem install ruby-vips
Successfully installed ruby-vips-2.1.3
Parsing documentation for ruby-vips-2.1.3
Done installing documentation for ruby-vips after 0 seconds
1 gem installed
✔ ~/pics 
13:25 $ irb
irb(main):001:0> require 'vips'
=> true
irb(main):002:0> x = Vips::Image.thumbnail("nina.jpg", 200)
=> #<Image 200x133 uchar, 3 bands, srgb>
irb(main):003:0> x.write_to_file("x.jpg")
=> nil
irb(main):006:0> Vips::VERSION
=> "2.1.3"
irb(main):009:0> Vips::version_string
=> "8.11.4-Thu Sep 23 09:40:01 UTC 2021"

My test image is here, in case that's a factor:

http://www.rollthepotato.net/~john/nina.jpg

This is a 2012 intel mac on 10.15.7.

[jcupitt]

We test and fuzz libvips on macos, eg:

https://github.com/libvips/libvips/runs/3873107160?check_suite_focus=true

So it shouldn't be a libvips-on-macos issue.

How are you installing ruby?

[shllg]

Installed it via rbenv.

The behavior seems to rely on the image files itself. Some images causing no problems. We tested the breaking images on other systems (linux) and they work. They are always the same images causing the problem.

[jcupitt]

Oh, that's interesting. Could you share one of these breaking images?

[shllg]

CASAAGUA.zip

Just two examples...

[jcupitt]

I tried your image with brew ruby and it seems to work:

13:44 $ irb
irb(main):001:0> require 'vips'
=> true
irb(main):002:0> x = Vips::Image.thumbnail("CASAAGUA-PIC-ES.jpeg", 200)
=> #<Image 200x133 uchar, 3 bands, srgb>
irb(main):003:0> x.write_to_file("x.jpg")
=> nil
irb(main):004:0> 

Is that what triggers the crash for you?

[jcupitt]

I tried with rbenv 2.7.4 as well and that also worked:

13:47 $ rbenv install 2.7.4
Downloading openssl-1.1.1l.tar.gz...
-> https://dqw8nmjcqpjn7.cloudfront.net/0b7a3e5e59c34827fe0c3a74b7ec8baef302b98fa80088d7f9153aa16fa76bd1
Installing openssl-1.1.1l...
Installed openssl-1.1.1l to /Users/john/.rbenv/versions/2.7.4

Downloading ruby-2.7.4.tar.bz2...
-> https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.4.tar.bz2
Installing ruby-2.7.4...
ruby-build: using readline from homebrew
Installed ruby-2.7.4 to /Users/john/.rbenv/versions/2.7.4

✔ ~/pics 
15:06 $ rbenv shell 2.7.4
✔ ~/pics 
15:06 $ ruby --version
ruby 2.7.4p191 (2021-07-07 revision a21a3b7d23) [x86_64-darwin19]
✔ ~/pics 
15:06 $ gem install ruby-vips
Fetching ruby-vips-2.1.3.gem
Fetching ffi-1.15.4.gem
Building native extensions. This could take a while...
Successfully installed ffi-1.15.4
Successfully installed ruby-vips-2.1.3
Parsing documentation for ffi-1.15.4
Installing ri documentation for ffi-1.15.4
Parsing documentation for ruby-vips-2.1.3
Installing ri documentation for ruby-vips-2.1.3
Done installing documentation for ffi, ruby-vips after 6 seconds
2 gems installed
✔ ~/pics 
15:07 $ irb 
irb(main):001:0> require 'vips'
=> true
irb(main):003:0> x = Vips::Image.thumbnail("CASAAGUA-PIC-ES.jpeg", 200)
=> #<Image 200x133 uchar, 3 bands, srgb>
irb(main):004:0> x.write_to_file("x.jpg")
=> nil
irb(main):005:0> 

How are you triggering the crash? Is this just in rails?

[developius]

I think I just bumped into this on production. The file in question is a bog-standard 1.7MB 3088x2316px JPEG, but we're seeing it for multiple different files of varying types.

We're seeing a segmentation fault occurring in vips_cache_operation_build.

• Ruby v2.7.6
• Rails v7.0.3
• ruby-vips v2.1.4

This is on Heroku (stack 20 - Ubuntu 20.04), we're using these buildpacks:

• https://github.com/heroku/heroku-buildpack-apt, Aptfile contains:
  • libglib2.0-0
  • libglib2.0-dev
  • libpoppler-glib8
• https://github.com/brandoncc/heroku-buildpack-vips

Started GET "/rails/active_storage/representations/redirect/<sgid>/<variant>/7C181624-33C3-4399-97D2-A1F716FCD947.jpeg" for 162.158.78.117 at 2022-07-04 17:09:06 +0100
Processing by ActiveStorage::Representations::RedirectController#show as JPEG
  Parameters: {"signed_blob_id"=>"<sgid>", "variation_key"=>"[FILTERED]", "filename"=>"7C181624-33C3-4399-97D2-A1F716FCD947"}
    S3 Storage (857.8ms) Downloaded file from key: <key>

(puma:4): GLib-GObject-CRITICAL **: 17:09:08.395: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
/app/vendor/bundle/ruby/2.7.0/gems/ruby-vips-2.1.4/lib/vips/operation.rb:225: [BUG] Segmentation fault at 0x00000000000000c8
ruby 2.7.6p219 (2022-04-12 revision c9c2245c0a) [x86_64-linux]

-- Control frame information -----------------------------------------------
c:0140 p:---- s:1088 e:001087 CFUNC  :vips_cache_operation_build
c:0139 p:0012 s:1083 e:001082 METHOD /app/vendor/bundle/ruby/2.7.0/gems/ruby-vips-2.1.4/lib/vips/operation.rb:225
c:0138 p:0363 s:1078 E:000938 METHOD /app/vendor/bundle/ruby/2.7.0/gems/ruby-vips-2.1.4/lib/vips/operation.rb:483
c:0137 p:0027 s:1057 e:001056 METHOD /app/vendor/bundle/ruby/2.7.0/gems/ruby-vips-2.1.4/lib/vips/image.rb:229

Full log

[developius]

I think I just bumped into this on production.

This turned out to be an issue with our vips dependencies, this fixed it:

diff --git a/Aptfile b/Aptfile
index 73561db1f..1d7617804 100644
--- a/Aptfile
+++ b/Aptfile
@@ -1 +1,3 @@
-libvips
\ No newline at end of file
+libglib2.0-0
+libglib2.0-dev
+libpoppler-glib8
\ No newline at end of file

[jcupitt]

Hi @developius, I'm glad it's fixed, but I'm puzzled how this change resolved the issue. You'd think no processing could happen with missing libraries.

Were you seeing unreliable image handling, or no image handling?

[developius]

@jcupitt apologies for the slow response here. I can't quite recall, but it did feel intermittent to me, although I'm now wondering if that was because some variants had already been generated some other way. I was messing with dependencies at the time, so it's possible that one setup worked for a time, then I switched to one which didn't. That would give me some images which were already processed, plus some which weren't, perhaps making it look intermittent. Not sure any of that is particularly helpful, but wanted to close the loop on my experience.

[Nakilon]

I wonder if vips could automatically (if you turn on some option) add metadata to image file which exactly version was used to generate it.

[GeoffreyOnRails]

I am having the same issue, also on Heroku 20 and using it via ActiveStorage, and I can confirm it's intermittent, some thumbnails work, some other don't. I noticed that we didn't install the libraries in out Aptfile, but it didn't change the outcome (most pictures works, some other don't).

[jcupitt]

If you have an image which always fails, that'd be great! If it seems random, this will be much harder to find :(

Are you using Brandon's libvips?

https://elements.heroku.com/buildpacks/brandoncc/heroku-buildpack-vips

I'd recommend that over the official heroku libvips.

[GeoffreyOnRails]

We do have an image which always fail, but unfortunately, it's an identity picture, so we can't share it.

I've done some investigations, and more specifically, the segfault occurs when I try to do an autorot on this image (I used the code below)

  image = Vips::Image.new_from_file(file.path)
  image.autorot #Crash

With the buildpack, the issue is no longer there, therefore, I suspect that the latest version of vips fixes the issue. I would like to try on heroku-22 to see whether that fixes the issue (since vips is at an higher vips8.12.1-1build1 version, compared to heroku-20's vips version 8.9.1-2), but we have to upgrade our version of ruby for that.

I'll try the test again once our codebase upgrade will be done.