FS#34630 - [skype] Segfault in the presence of glib2 2.36
Attached to Project:
Community Packages
Opened by Reda Lazri (rAX) - Friday, 05 April 2013, 16:53 GMT
Last edited by Evangelos Foutras (foutrelis) - Wednesday, 03 July 2013, 19:42 GMT
Opened by Reda Lazri (rAX) - Friday, 05 April 2013, 16:53 GMT
Last edited by Evangelos Foutras (foutrelis) - Wednesday, 03 July 2013, 19:42 GMT
This task depends upon
Closed by Evangelos Foutras (foutrelis)
Wednesday, 03 July 2013, 19:42 GMT
Reason for closing: Fixed
Additional comments about closing: lib32-glib2 2.36.3-2
Wednesday, 03 July 2013, 19:42 GMT
Reason for closing: Fixed
Additional comments about closing: lib32-glib2 2.36.3-2
You should also know that whatever is going on there is most likely not properly fixable since we can't recompile skype.
glib2: 2.36.0-5
> Please provide backtraces
Any hints on how to do that? gdb doesn't work with it.
> You should also know that whatever is going on there is most likely not properly fixable since we can't recompile skype.
Yeah. :s
GNU gdb (GDB) 7.5.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/lib/skype/skype...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/lib/skype/skype
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x080796e8 in malloc@plt ()
uname -r -m 3.8.7-1-ARCH x86_64
gnome 3.8.1
but the problem is what gdb says:
GNU gdb (GDB) 7.5.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
"/usr/bin/skype": not in executable format: File format not recognized
Skype segfaults. It's a binary provided by upstream; we cannot do anything about it. Just follow the upstream bug report and blame them.
modemmanager-0.7.990-2-x86_64
lirc-utils-1:0.9.0-42-x86_64
virtualbox-host-modules-4.2.12-2-x
gtk2-perl-1.247-1-x86_64
pango-perl-1.224-1-x86_64
cairo-perl-1.103-1-x86_64
apr-util-1.5.2-1-x86_64
glib-perl-1.280-1-x86_64
clutter-1.14.2-1-x86_64
gtkmm3-3.8.0-1-x86_64
poppler-0.22.3-2-x86_64
poppler-glib-0.22.3-2-x86_64
poppler-qt-0.22.3-2-x86_64
gdm-3.8.1.1-1-x86_64
libgdm-3.8.1.1-1-x86_64
ib32-glib2-2.36.1-1-x86_64
xorg-server-1.14.1-1-x86_64
xorg-server-common-1.14.1-1-x86_
lib32-pango-1.34.0-1-x86_64
lib32-fontconfig-2.10.92-1-x86_64
icedtea-web-java7-1.3.2-1-x86_64
linux-headers-3.8.8-1-x86_64
linux-3.8.8-1-x86_64
gpsd-3.8-1-x86_64
docbook-xsl-1.78.1-1-any
alsa-utils-1.0.27-4-x86_64
opencv-2.4.5-2-x86_64
kdelibs-4.10.2-2-x86_64
gbrainy-1:2.2.0-1-any
gegl-0.2.0-7-x86_64
at-spi2-atk-2.8.1-1-x86_64
mediastreamer-2.8.2-5-x86_64
Segmentation fault (core dumped)
downgrading to lib32-glib2 2.34.3-1 fixed the problem.
Either way the commit 28b30caecb8d53c0d41e6a46ef9ba01d2f08e051, has "evolved" into the configure argument --disable-compile-warnings
Rebuilding with or without the switch does not change anything
Bernhard, can you check if anything else has changed between master(good) and the 2.36(bad) branch
Thanks
user@host$ LD_PRELOAD=/path/to/lib32-glib2-2.34.3-1-x86_64.pkg/usr/lib32/libgobject-2.0.so.0.3400.3 skype
Edit: credit goes to ViruSzZ from this thread - https://bbs.archlinux.org/viewtopic.php?pid=1262153
if test "x$GCC" = "xyes"; then
case " $CFLAGS " in
*[[\ \ ]]-Wall[[\ \ ]]*) ;;
*) CFLAGS="$CFLAGS -Wall" ;;
esac
fi
Restoring just these lines makes skype work again, too.
Reverting the first hunk of 28b30caecb8d53c0d41e6a46ef9ba01d2f08e051 does solve the issue on my x86-64 system
Which begs the questions
1. "Wall is causing runtime issues... Really ?"
2. "Wall is constantly needed ;)"
Anyway, the patch for ABS/PKGBUILD is attached. i686 could use similar treatment
thx
https://bugs.archlinux.org/task/34892
ty
configure:21628: checking if malloc() and friends prototypes are gmem.h compatible
-configure:21654: gcc -c -g -O2 -Werror conftest.c >&5
-configure:21654: $? = 0
-configure:21663: result: yes
+configure:21654: gcc -c -Wall -Werror conftest.c >&5
+conftest.c: In function 'main':
+conftest.c:66:13: error: variable 'my_realloc_p' set but not used [-Werror=unused-but-set-variable]
+ void* (*my_realloc_p) (void*, size_t) = realloc;
+ ^
+conftest.c:65:13: error: variable 'my_free_p' set but not used [-Werror=unused-but-set-variable]
+ void (*my_free_p) (void*) = free;
+ ^
+conftest.c:64:13: error: variable 'my_malloc_p' set but not used [-Werror=unused-but-set-variable]
+ void* (*my_malloc_p) (size_t) = malloc;
+ ^
+conftest.c:63:13: error: variable 'my_calloc_p' set but not used [-Werror=unused-but-set-variable]
+ void* (*my_calloc_p) (size_t, size_t) = calloc;
+ ^
+cc1: all warnings being treated as errors
+configure:21654: $? = 1
Because of this, without -Wall "#define SANE_MALLOC_PROTOS 1" gets set in config.h, and gets unset with -Wall. I verified this to be the real culprit: take the current lib32-glib2 PKGBUILD, remove the today's CFLAGS fix and add "sed -ie '/SANE_MALLOC_PROTOS/d' config.h" between ./configure and make. It will give the same result (Skype works).
Hence, ./configure actually _works as intended_ without -Wall, and -Wall messes this up due to wrong -Werror usage in ./configure (bug #1). It follows that without -Wall the software gets configured correctly, and this triggers a bug somewhere in Glib (bug #2); with -Wall the software gets configured incorrectly, Glib somehow works despite that and the bug is not triggered.
Should this go in upstream bugzilla?
$ gdb /usr/lib32/skype/skype
(gdb) break g_malloc
Function "g_malloc" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (g_malloc) pending.
(gdb) run
Starting program: /usr/lib32/skype/skype
Breakpoint 1, 0xf52082c0 in g_malloc () from /usr/lib32/libglib-2.0.so.0
(gdb) bt
#0 0xf52082c0 in g_malloc () from /usr/lib32/libglib-2.0.so.0
#1 0xf52085ab in g_malloc_n () from /usr/lib32/libglib-2.0.so.0
#2 0xf52122d7 in g_quark_from_static_string () from /usr/lib32/libglib-2.0.so.0
#3 0xf5090902 in ?? () from /usr/lib32/libgobject-2.0.so.0
#4 0xf7feae7e in call_init () from /lib/ld-linux.so.2
#5 0xf7feaf4c in _dl_init_internal () from /lib/ld-linux.so.2
#6 0xf7fdd0cf in _dl_start_user () from /lib/ld-linux.so.2
g_malloc() gets called from within the library init function of libgobject, which should not be a problem. libgobject links to libglib, so libglib is presumably loaded and initialized at this point. g_malloc() calls into a function table (the one you can change with g_mem_set_vtable()) to call the right memory allocation backend. Here's where things get interesting.
If SANE_MALLOC_PROTOS is defined, the function table is simply initialized with a pointer to glibc's malloc(). Otherwise, it is initialized with a pointer to a thin wrapper function around malloc(). In either case, ld-linux.so has to do some relocation magic to fix up the address of malloc(), depending on what address glibc is mapped to. As it happens, this bug only affects the pointer to malloc(), not the wrapper function; that's why the crash goes away if SANE_MALLOC_PROTOS is not defined.
It gets more complicated, because the pointer to malloc() does not hold the actual address of malloc() but the address of an entry in the ELF object's procedure linkage table (PLT). Furthermore, each ELF object (libglib.so, the skype binary, etc.) has its own PLT, and they are initialized at different times. Ignoring this fact, ld-linux.so resolves g_malloc()'s pointer to malloc() using the PLT in the skype binary, not the one in libglib.so. When g_malloc() gets called during libgobject initialization, the PLT in the skype binary has not been initialized yet! Hence, we happily start executing random bytes as machine code, causing a segmentation fault or worse.
Below, GDB reports that there are 31 different "malloc@plt" entries in 31 different PLTs. Examining the addresses shows that the entry at 0xf7fdc8a0 belongs to libglib.so while the one at 0x080796e8 belongs to the skype binary. g_malloc() therefore ought to call address 0xf7fdc8a0, but instead calls 0x080796e8. (In this case, the instruction at 0x080796e8 happened to be "in 24h, eax", which immediately triggered SIGSEGV.)
(gdb) break malloc@plt
Breakpoint 2 at 0xf7fdc8a0 (31 locations)
(gdb) cont
Continuing.
Breakpoint 2, 0x080796e8 in malloc@plt ()
(gdb) info break
...
2.16 y 0xf51d0b00 <malloc@plt>
...
2.31 y 0x080796e8 <malloc@plt>
(gdb) info proc map
process 19070
Mapped address spaces:
Start Addr End Addr Size Offset objfile
0x8048000 0x9ba4000 0x1b5c000 0x0 /usr/lib32/skype/skype
...
0xf51bc000 0xf52bc000 0x100000 0x0 /usr/lib32/libglib-2.0.so.0.3600.1
...
multilib/skype 4.2.0.11-3
multilib/lib32-glib2 2.36.3-2
Sorry for wasting your time. I must get around to updating the couple of PKGBUILDs I've uploaded to AUR and actually contribute back. Thanks all!