Possible out of bound unref of image pointer

Excerpts from stack trace:

malloc_consolidate(): invalid chunk size corrupted size vs. prev_size SIGABRT: abort

....

runtime.cgocall(0x760e20, 0xc420292340, 0x42e824) /usr/local/go/src/runtime/cgocall.go:128 +0x64 fp=0xc420292310 sp=0xc4202922d8 pc=0x405b04 github.com/h2non/bimg._Cfunc_g_object_unref(0x7f1f1404b190) _cgo_gotypes.go:456 +0x41 fp=0xc420292340 sp=0xc420292310 pc=0x6e3391 github.com/h2non/bimg.vipsSave.func1(0x7f1f1404b190) /go/src/github.com/h2non/bimg/vips.go:400 +0x56 fp=0xc420292378 sp=0xc420292340 pc=0x6ed286

Then looking at: https://github.com/h2non/bimg/blob/master/vips.go#L392 https://github.com/h2non/bimg/blob/master/vips.go#L400

It seems as though the g_object_unref call in vipsPreSave is unneeded as vipsSave calls g_object_unref regardless?

@eriken is there any progress here ? i met a similar problem too: https://github.com/h2non/imaginary/issues/306

@nullne Sadly no, we ended up using ImageMagick through CLI. What we lost in performance we certainly gained in stability.

@eriken it works good if i set limitation on QPS. i'll try to find out the root cause

p.s have you ever tried imgproxy? seems a good alternative of imaginary

Are you guys doing locks on vips calls? Due to the memory caching within vips, I dont think it is threadsafe and it would explain the pointer unref issues during high QPS.

The same problem and stacktrace. In my case a preSave don't calls unref for an image :( I tried it on libvips 8.11.2 and 8.9.2

I have found solution , vips_vector_set_enabled(0) may help for that. After 10h load tests no problems with memory and panics.

hello, I encountered the same problem, does vips_vector_set_enabled() have any effect in the end? @ZloyDyadka