Arch Linux

I do not have any i686 system so I can't test. Please provide backtraces and version information.

You should also know that whatever is going on there is most likely not properly fixable since we can't recompile skype.

Skype: 4.1.0.20-6
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

"Doesn't work" doesn't help, sorry. Please provide error message or at least describe/show what you tried and what happened.

gdb /usr/lib/skype/skype
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 ()

on x86_64 Skype segfaults with lib32-glib2 2.36.1-1. Downgrade fixes it.

Corresponding upstream report: https://jira.skype.com/browse/SCL-977

I have the same problems after my yestfrday's upgrade. I ahve glib2-2.36.1-1 installed but is not a glib2 problem since skype was already running with glib2-2.36.0-5. I downgraded the kernel from 3.8.8 to 3.8.7 but nothing changed.
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

I ran into that as well. /usr/bin/skype is only a wrapper. And skype is 32 bit, so lib32-glib2 is the culprit on x86_64 systems.

Please stop pasting GDB license headers.

Skype segfaults. It's a binary provided by upstream; we cannot do anything about it. Just follow the upstream bug report and blame them.

yes maybe, but lib32-glibc was already there and I did not have any problem. ANyway here is my upgrade lit of yesterday:

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

@enumealis: lib32-glib2 is your problem. The upstream bug report has a workaround. See comment by bluewind.

Sorry, I read Bluewind and reinstalled glib2-2.34.3-1 but forgot to reinstall lib32-gòlib2 aslso. Now it works thanks.

Duplicated on my x64_86 system, I fixed by manually reverting to lib32-glib3 2.34.3.1

Skype ships QtWebKit library iirc. Can't it ship libgobject-2.0.so (or all Glib libraries), too?

I can confirm, reverting to lib32-glib2-2.34.3-1 fixes problem. Skype from multilib repo, x86_64 Arch.

Skype could probably just ship with glib2 2.34.3.1 statically, and the desktop file could be modified to preload the library.

same here. having lib32-glib2 2.36.1-1 installed, skype crashes with:

Segmentation fault (core dumped)

downgrading to lib32-glib2 2.34.3-1 fixed the problem.

The crash happens since commit 28b30caecb8d53c0d41e6a46ef9ba01d2f08e051 ("configure: Enable set of standard -Werror=foo flags") in the glib repository. Reverting that commit on the master branch makes skype work again.

Bernhard did you manage to revert the patch cleanly on top of the 2.36 branch ? Having some difficulties here

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

As a workaround without downgrading glib2, skype can be run as such:
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

Same here, temporarily fixed with caligula's workaround

Worked for me too. Maybe skype package should come with this workaround by default? I'm not counting on M$ to fix it themselves...

I've looked into it more closely. The commit mentioned above removes the follwing lines in configure.ac:

if test "x$GCC" = "xyes"; then
case " $CFLAGS " in
*[[\ \ ]]-Wall[[\ \ ]]*) ;;
*) CFLAGS="$CFLAGS -Wall" ;;
esac
fi

Restoring just these lines makes skype work again, too.

Gratitude Bernhard
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

It doesn't make sense, -Wall shouldn't change how a file is built...

Doesn't make sense, but works. Thanks very much for bisecting that. I've pushed a new lib32-glib2 package.

Rather than patching, does simply adding -Wall to CFLAGS help?

Right, totally forgot the easy way. Yes, adding -Wall to the CFLAGS also fixes the issue.

Pushed a new glib2 to testing for i686 and x86_64. Someone please test if this fixes skype on i686.

skype works for me after updating to lib32-glib2-2.36.1-3-x86_64

thx

works after update to lib32-glib2-2.36.1-3-x86_64

I think this may be the same issue too.. it's affecting much more than just skype:
https://bugs.archlinux.org/task/34892

Thanks for fixing the package, Skype works beautifully again on my x86_64 system!

skype works again on i686 with glib2-2.36.1-2
ty

I configured vanilla 2.36.1 Glib tarball with ./configure and with CFLAGS="-Wall" ./configure, then diffed the resulting directories. Analyzing the diff, I found this (edited):

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?

I think this is not a bug in Skype or in GLib but in ld-linux.so.

$ 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
...

Nice find! Meanwhile, I reported bug #1 to the upstream: https://bugzilla.gnome.org/show_bug.cgi?id=698716

It looks like with the next release of glib2 this bug will reappear again if Skype doesn't get fixed: https://bugzilla.gnome.org/show_bug.cgi?id=698716#c9

@Emil: This has nothing to do with the glib2 ABI/API. The crash is simply due to calling malloc() from the shared library init function. The only thing you can blame the Gnome folks for is using an ELF feature that GNU/Linux does not implement correctly.

As mentioned on the upstream Gnome report, Skype 4.2 works without the -Wall workaround (it has a statically-initialized PLT).

Bumped lib32-glib2 and removed the workaround. Please test lib32-glib2 2.36.3-2 from multilib-testing before I move it, just to be sure.

Yes, lib32-glib2 2.36.3-2 works fine for me. Thanks everybody for looking into it!

Works for me.

https://bugs.archlinux.org/task/35932

Works for me - x86_64, testing enabled, all repos up to date (2013-06-26)

Works like a charm, x86-64
multilib/skype 4.2.0.11-3
multilib/lib32-glib2 2.36.3-2

I'll close this again then unless Alex comments here in the next few days.

Please close - I was running an old version of skype (/usr/local/bin/skype). Now I just need to work out how to remove that!
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!