|
Description
|
A tools- xxxxx@xxxxx.org post observed a failure in loading firefox:
% ./dist/bin/firefox
ld.so.1: firefox-bin: fatal: /usr/lib/libcairo.so.2: Invalid argument
ld.so.1: firefox-bin: fatal: relocation error: file /usr/lib/libgtk-x11-2.0.so.0: symbol cairo_surface_destroy: referenced symbol not found
ld.so.1: firefox-bin: fatal: /usr/lib/libgdk-x11-2.0.so.0: Invalid argument
ld.so.1: firefox-bin: fatal: /usr/lib/libgdk_pixbuf-2.0.so.0: Invalid argument
ld.so.1: firefox-bin: fatal: /usr/lib/libgobject-2.0.so.0: Invalid argument
........
Investigation of truss output revealed that prior to this failure, the hardware
capabilities processing of libmlib was carried out. This processing has left
behind stale information that has confused later mapping attempts:
openat(AT_FDCWD, "/usr/lib/libmlib", O_RDONLY|O_NDELAY|O_LARGEFILE) = 3
mmap(0x00000000, 12288, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1
, 0) = 0xFBB70000
fcntl(3, F_SETFD, 0x00000001) = 0
fstat64(3, 0x08045850) = 0
getdents64(3, 0xFBB70018, 8192) = 112
xstat(2, "/usr/lib/libmlib/amd64", 0x08045408) = 0
getdents64(3, 0xFBB70018, 8192) = 0
close(3) = 0
.....
xstat(2, "/usr/lib/libcairo.so.2", 0x08045D18) = 0
resolvepath("/usr/lib/libcairo.so.2", "/usr/lib/libcairo.so.2.11.3", 1023) = 27
open("/usr/lib/libcairo.so.2", O_RDONLY) = 3
mmap(0x00000000, 0, PROT_READ|PROT_EXEC, 0, 3, 0) Err#22 EINVAL
The mmap failure is the source of the rejection message.
libmlib was loaded much earlier in the process, and its filtee, libmlib_sse2.so.2
was also loaded. However, for some reason libmlib seems to have been unmapped
while the filtee has stayed around. When libmlib is loaded again, the filtee is
already available, and this scenario seems to have triggered the hwcap/filtering
logic to leave behind the stale information.
It's possible that the removal of libmlib without removal of the filtee is another
problem to solve.
|
