signal: segmentation fault #291
Comments
|
And another crash, but this time I got something more: |
|
I forgot to add some lines of the trace that could be useful. |
|
Possibly related to: But I am not sure I can do anything to resolve this myself if it's |
|
We're getting these as well, about ~1 per day. Any suggestion on how to mitigate this one? Should we maybe, for goroutines that trigger vips, use https://pkg.go.dev/runtime/debug#SetPanicOnFault (not sure that one would even do anything for cgo)? Here are snippets from 3 crashes, I guess these routines are the ones that actually get SIGSEGV: |
|
+1,by the way, vips._Cfunc_load_from_buffer also cause crash,when |
|
I have tested this on Linux CentOS 9 (Rocky Linux 9) and it happens there as well, so it's not WSL related. Here's an example trace: |
|
I am experiencing this exact same issue. @bjg2 I tried a little snippet but it seems that SetPanicOnFault does not work with a C segementation fault. This is the explanation that I found: https://groups.google.com/g/golang-nuts/c/j4npkSTUZFs My system is an Ubuntu in aws, so is not WSL related. If anyone have found a workaround I would love to know. Thanks! |
|
We are also facing similar issues, our application crashes about ~1 per day with SIGSEGV or SIGABRT, with different reasons. Errors are usually in the Composite, Export and Close methods. |
|
We mitigated by creating new processes that do vips stuff, and channeling data to them via stdin and from them via stdout. Very not cool but it works - if vips process crashes main process stays alive. It would be much better if process would never crash, but I guess big part of engineering is getting the best out of the black box... :) |
|
@Delicious-Bacon The threads that you have shared state the issue in glibc when static binaries are used. I am not creating statically linked binary, could the failures still be due to the stated glibc bug? |
Not sure what do you mean by "statically linked binary" in your case. As for my case, I ran my code via |
|
I am also getting SIGSEGV after calling I can't tell whether this is govips or libvips related |
|
I found out that the root of the problem was that some images had grayscale/b-w color space, and calling |
|
Hello, @rafaelsierra |
|
I finally had time to look deeper into the issue and (obviously) it's user error. This is the minimum code I need to reproduce the sigsegv: package main
import (
"encoding/base64"
"log"
"os"
"github.com/davidbyttow/govips/v2/vips"
)
// transparentPixelData contains a 1x1 webp transparent image
const transparentPixelData = `UklGRuoCAABXRUJQVlA4WAoAAAAwAAAAAAAAAAAASUNDUKACAAAAAAKgbGNtcwQwAABtbnRyUkdC
IFhZWiAH5wACABAACQAoADVhY3NwQVBQTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAA
AADTLWxjbXMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1k
ZXNjAAABIAAAAEBjcHJ0AAABYAAAADZ3dHB0AAABmAAAABRjaGFkAAABrAAAACxyWFlaAAAB2AAA
ABRiWFlaAAAB7AAAABRnWFlaAAACAAAAABRyVFJDAAACFAAAACBnVFJDAAACFAAAACBiVFJDAAAC
FAAAACBjaHJtAAACNAAAACRkbW5kAAACWAAAACRkbWRkAAACfAAAACRtbHVjAAAAAAAAAAEAAAAM
ZW5VUwAAACQAAAAcAEcASQBNAFAAIABiAHUAaQBsAHQALQBpAG4AIABzAFIARwBCbWx1YwAAAAAA
AAABAAAADGVuVVMAAAAaAAAAHABQAHUAYgBsAGkAYwAgAEQAbwBtAGEAaQBuAABYWVogAAAAAAAA
9tYAAQAAAADTLXNmMzIAAAAAAAEMQgAABd7///MlAAAHkwAA/ZD///uh///9ogAAA9wAAMBuWFla
IAAAAAAAAG+gAAA49QAAA5BYWVogAAAAAAAAJJ8AAA+EAAC2xFhZWiAAAAAAAABilwAAt4cAABjZ
cGFyYQAAAAAAAwAAAAJmZgAA8qcAAA1ZAAAT0AAACltjaHJtAAAAAAADAAAAAKPXAABUfAAATM0A
AJmaAAAmZwAAD1xtbHVjAAAAAAAAAAEAAAAMZW5VUwAAAAgAAAAcAEcASQBNAFBtbHVjAAAAAAAA
AAEAAAAMZW5VUwAAAAgAAAAcAHMAUgBHAEJBTFBIAgAAAAAAVlA4IBoAAAAwAQCdASoBAAEAAAAA
JaQAA3AA/v/fbtQAAA==
`
func main() {
ip := vips.NewImportParams()
ip.FailOnError.Set(false)
buff, _ := os.ReadFile("p.png")
im, _ := vips.NewImageFromBuffer(buff)
im.OptimizeICCProfile()
im.Resize(2, vips.KernelLanczos3)
b, _ := base64.StdEncoding.DecodeString(transparentPixelData)
canvas, _ := vips.LoadImageFromBuffer(b, vips.NewImportParams())
canvas.ResizeWithVScale(float64(im.Width()), float64(im.Height()), vips.KernelAuto)
x := (canvas.Width() - im.Width()) / 2
y := (canvas.Height() - im.Height()) / 2
err := canvas.Composite(im, vips.BlendModeOver, x, y)
if err != nil {
log.Fatalf("failed to composite: %#v", err)
}
// Reduces the incoming image to 1x1 pixel
err = im.Thumbnail(1, 1, vips.InterestingNone)
if err != nil {
log.Fatalf("failed to thumbnail: %#v", err)
}
// Adds an alpha channel to make sure we can draw a transparent square in the
// entire image
err = im.AddAlpha()
if err != nil {
log.Fatalf("failed to add alpha: %#v", err)
}
// Makes the image a single transparent pixel
im.DrawRect(vips.ColorRGBA{A: 0}, 0, 0, 1, 1, true)
// Scales image back to the size of the canvas
// This will cause the application to crash
im.ResizeWithVScale(float64(canvas.Width()), float64(canvas.Height()), vips.KernelAuto)
}Where The issue is, of course, that If you are getting SIGSEGV, make sure that you are checking for errors every step of the way and stopping execution once an error happens. I have a linter setup that is supposed to catch missing error checks but I guess it is not properly configured. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I had a Go project running around 250 concurrent image processing routines and had a crash with the only message being
signal: segmentation fault.I am running Ubuntu 22.04. on WSL2.
I have seen this note on memory. Can it be related to that? If so, how/where would I set the
MALLOC_ARENA_MAX?Something else that might be interesting is the
ulimit -aoutput so I'll dump it here:The text was updated successfully, but these errors were encountered: