Created attachment 130497 [details] gdb backtrace I'm running a gtk3 app inside an Ubuntu docker container that load a page via WebKit and creates a snapshot of it. The problem I have is that in some web pages, the app would terminate with a SIGBUS signal. I've provided an attachment with the apps backtrace. I've eliminated gtk3 and webkit as the offending memory allocation happens inside cairo. I've done some browsing and found out that a pointer arithmetic in src/cairo-image-compositor.c @ _fill_xrgb32_lerp_opaque_spans causes unaligned memory access. Particularly, assignments like: *d = lerp8x4 (r->u.fill.pixel, a, *d); and: uint32_t *d = (uint32_t *)(r->u.fill.data + r->u.fill.stride*yy + spans[0].x*4); in the mentioned function seemed to be problematic as they end up being non-aligned. The interesting thing is that the exact same app doesn't fail on the host system, after running it for a long time. If interested, I can also provide a working test case in a form of a docker image. Software used: - x86-64 Ubuntu 16.04.1 on host - phusion/baseimage as container baseimage - Docker 1.12.3 - updated to Cairo 1.14.8 in container
Stride and data should be aligned. At a rough guess it seems that the data is not aligned. Was that cairo_image_surface_create_for_data perchance?
If you mean how do I get the surface ... I get it from gtk_offscreen_window_get_surface(window).
But I don't know what cairo operations does webkitgtk call. I'm using webkit2gtk-4.0
Why would that be giving you an image surface? Mysteries. Anyway, recompile the lot (cairo/pixmap definitely) with -O0 -g3 and get decent locals so we can see the source of the misalignment.
Created attachment 130498 [details] gdb backtrace Here's a more complete GDB backtrace
Created attachment 130527 [details] gdb backtrace Here's another backtrace, showing misalignment when using SSE2... Is it possible that this code doesn't work so well under Docker?
Any known solution for this. I am also seeing this error on my ubuntu docker instance and dont see that on regular ubuntu linux installation with same compiler and build tools.
The problem is in the shared memory device (/dev/shm) that is mounted inside the Docker container. By default, docker mounts it as a 64 MB (correct me if I'm wrong) filesystem, which might be too small for some applications. The solution is to specify --shm-size when running the container and increase the size. Or by sharing the system /dev/shm by adding it as a volume. The crashes vanished after resizing /dev/shm in the container.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.