Bug#964141: libc6: "cannot allocate memory in static TLS block" with some library combinations on arm64

2020-07-13 Thread Dmitry Shachnev 
Control: tags -1 + fixed-upstream

On Fri, Jul 03, 2020 at 03:57:36PM +0200, Gianfranco Costamagna wrote:
> control: tags -1 patch
>
> Hello, the patch (v5) applied on top of 2.31 (build-tested in Ubuntu)
> seems to solve the issue

Thanks for testing it!

Dear glibc maintainers: the patchset was updated to v6 and then committed
upstream a few days ago:

Cover mail: https://sourceware.org/pipermail/libc-alpha/2020-July/115968.html
PATCH 1/3: https://sourceware.org/git/?p=glibc.git;a=commit;h=0c7b002fac12dcb2
PATCH 2/3: https://sourceware.org/git/?p=glibc.git;a=commit;h=17796419b5fd6943
PATCH 3/3: https://sourceware.org/git/?p=glibc.git;a=commit;h=ffb17e7ba3a5ba96

Fix for this bug is in the third patch, but I guess it needs the first two
as well if you will be backporting it.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#964141: libc6: "cannot allocate memory in static TLS block" with some library combinations on arm64

2020-07-03 Thread Gianfranco Costamagna 
control: tags -1 patch

Hello, the patch (v5) applied on top of 2.31 (build-tested in Ubuntu) seems to 
solve the issue:

diff -Nru glibc-2.31/debian/changelog glibc-2.31/debian/changelog
--- glibc-2.31/debian/changelog 2020-06-11 09:53:48.0 +
+++ glibc-2.31/debian/changelog 2020-07-03 10:21:12.0 +
@@ -1,3 +1,9 @@
+glibc (2.31-0ubuntu11) groovy; urgency=medium
+
+  * Fix arm64 sadness on pyside2
+
+ -- Gianfranco Costamagna   Fri, 03 Jul 2020 
11:45:47 +0200
+
 glibc (2.31-0ubuntu10) groovy; urgency=medium
 
   * Copy the fully conditionalized x86 variant for math-vector-fortran.h 
diff -Nru glibc-2.31/debian/patches/arm64-fix-2.patch 
glibc-2.31/debian/patches/arm64-fix-2.patch
--- glibc-2.31/debian/patches/arm64-fix-2.patch 1970-01-01 00:00:00.0 
+
+++ glibc-2.31/debian/patches/arm64-fix-2.patch 2020-07-03 10:21:10.0 
+
@@ -0,0 +1,606 @@
+Origin: http://51.15.138.76/patch/37618/
+
+diff --git a/csu/libc-tls.c b/csu/libc-tls.c
+index e2603157e8..fb77cd94fa 100644
+--- a/csu/libc-tls.c
 b/csu/libc-tls.c
+@@ -56,6 +56,9 @@  size_t _dl_tls_static_align;
+loaded modules with IE-model TLS or for TLSDESC optimization.
+See comments in elf/dl-tls.c where it is initialized.  */
+ size_t _dl_tls_static_surplus;
++/* Remaining amount of static TLS that may be used for optimizing
++   dynamic TLS access (e.g. with TLSDESC).  */
++size_t _dl_tls_static_optional;
+ 
+ /* Generation counter for the dtv.  */
+ size_t _dl_tls_generation;
+diff --git a/elf/Makefile b/elf/Makefile
+index 6fe1df90bb..5fadaec27c 100644
+--- a/elf/Makefile
 b/elf/Makefile
+@@ -201,7 +201,7 @@  tests += restest1 preloadtest loadfail multiload origtest 
resolvfail \
+tst-unwind-ctor tst-unwind-main tst-audit13 \
+tst-sonamemove-link tst-sonamemove-dlopen tst-dlopen-tlsmodid \
+tst-dlopen-self tst-auditmany tst-initfinilazyfail tst-dlopenfail \
+-   tst-dlopenfail-2
++   tst-dlopenfail-2 tst-tls-ie tst-tls-ie-dlmopen
+ #  reldep9
+ tests-internal += loadtest unload unload2 circleload1 \
+neededtest neededtest2 neededtest3 neededtest4 \
+@@ -312,7 +312,11 @@ modules-names = testobj1 testobj2 testobj3 testobj4 
testobj5 testobj6 \
+   tst-auditmanymod7 tst-auditmanymod8 tst-auditmanymod9 \
+   tst-initlazyfailmod tst-finilazyfailmod \
+   tst-dlopenfailmod1 tst-dlopenfaillinkmod tst-dlopenfailmod2 \
+-  tst-dlopenfailmod3 tst-ldconfig-ld-mod
++  tst-dlopenfailmod3 tst-ldconfig-ld-mod \
++  tst-tls-ie-mod0 tst-tls-ie-mod1 tst-tls-ie-mod2 \
++  tst-tls-ie-mod3 tst-tls-ie-mod4 tst-tls-ie-mod5 \
++  tst-tls-ie-mod6
++
+ # Most modules build with _ISOMAC defined, but those filtered out
+ # depend on internal headers.
+ modules-names-tests = $(filter-out ifuncmod% tst-libc_dlvsym-dso tst-tlsmod%,\
+@@ -1699,3 +1702,23 @@  $(objpfx)tst-auxobj: $(objpfx)tst-filterobj-aux.so
+ 
+ $(objpfx)tst-ldconfig-ld_so_conf-update.out: $(objpfx)tst-ldconfig-ld-mod.so
+ $(objpfx)tst-ldconfig-ld_so_conf-update: $(libdl)
++
++$(objpfx)tst-tls-ie: $(libdl) $(shared-thread-library)
++$(objpfx)tst-tls-ie.out: \
++  $(objpfx)tst-tls-ie-mod0.so \
++  $(objpfx)tst-tls-ie-mod1.so \
++  $(objpfx)tst-tls-ie-mod2.so \
++  $(objpfx)tst-tls-ie-mod3.so \
++  $(objpfx)tst-tls-ie-mod4.so \
++  $(objpfx)tst-tls-ie-mod5.so \
++  $(objpfx)tst-tls-ie-mod6.so
++
++$(objpfx)tst-tls-ie-dlmopen: $(libdl) $(shared-thread-library)
++$(objpfx)tst-tls-ie-dlmopen.out: \
++  $(objpfx)tst-tls-ie-mod0.so \
++  $(objpfx)tst-tls-ie-mod1.so \
++  $(objpfx)tst-tls-ie-mod2.so \
++  $(objpfx)tst-tls-ie-mod3.so \
++  $(objpfx)tst-tls-ie-mod4.so \
++  $(objpfx)tst-tls-ie-mod5.so \
++  $(objpfx)tst-tls-ie-mod6.so
+diff --git a/elf/dl-reloc.c b/elf/dl-reloc.c
+index ffcc84d396..6d32e49467 100644
+--- a/elf/dl-reloc.c
 b/elf/dl-reloc.c
+@@ -39,13 +39,16 @@ 
+ /* We are trying to perform a static TLS relocation in MAP, but it was
+dynamically loaded.  This can only work if there is enough surplus in
+the static TLS area already allocated for each running thread.  If this
+-   object's TLS segment is too big to fit, we fail.  If it fits,
+-   we set MAP->l_tls_offset and return.
+-   This function intentionally does not return any value but signals error
+-   directly, as static TLS should be rare and code handling it should
+-   not be inlined as much as possible.  */
++   object's TLS segment is too big to fit, we fail with -1.  If it fits,
++   we set MAP->l_tls_offset and return 0.
++   A portion of the surplus static TLS can be optionally used to optimize
++   dynamic TLS access (with TLSDESC or powerpc TLS optimizations).
++   If OPTIONAL is true then TLS is allocated for such optimization and
++   the caller must have a fallback in case the optional portion of surplus
++   TLS runs out.  If OPTIONAL is false then the entire surplus TLS area is
++   considered and the allocation only fails if

Bug#964141: libc6: "cannot allocate memory in static TLS block" with some library combinations on arm64

2020-07-02 Thread Dmitry Shachnev 
Package: libc6
Version: 2.30-8
Control: block 960073 by -1

Dear glibc maintainers,

Originally I got two reports about issues when loading Qt WebEngine library
from Python using PyQt and PySide bindings, see #960073 and #963709 for
context.

However I can reproduce it without any Python code and even without Qt.

The attached C program tries to load three popular libraries: libsystemd.so.0,
libavformat.so.58 (from ffmpeg) and libglapi.so.0 (from mesa).

When trying to run it on arm64, I get the following:

$ gcc test.c -ldl
$ ./a.out
Failed to load libglapi.so.0: /usr/lib/aarch64-linux-gnu/libglapi.so.0: cannot 
allocate memory in static TLS block

This does not happen on other architectures. This makes me think the amount
of TLS storage on arm64 is too low, can it be somehow increased?

When swapping second and third blocks, it works fine.

Here is an upstream bug report that may be related:
https://sourceware.org/bugzilla/show_bug.cgi?id=25051

And here is patch, currently under review, that may be also related:
https://sourceware.org/pipermail/libc-alpha/2020-May/114247.html

If you think it is a bug not in glibc/dlopen but in one of these libraries,
please let me know.

--
Dmitry Shachnev
#include 
#include 

int main() {
void *systemd_handle, *avformat_handle, *glapi_handle;

systemd_handle = dlopen("libsystemd.so.0", RTLD_LAZY);
if (!systemd_handle) {
printf("Failed to load libsystemd.so.0: %s\n", dlerror());
}

avformat_handle = dlopen("libavformat.so.58", RTLD_LAZY);
if (!avformat_handle) {
printf("Failed to load libavformat.so.58: %s\n", dlerror());
return 1;
}

glapi_handle = dlopen("libglapi.so.0", RTLD_LAZY);
if (!glapi_handle) {
printf("Failed to load libglapi.so.0: %s\n", dlerror());
return 1;
}

dlclose(glapi_handle);
dlclose(avformat_handle);
dlclose(systemd_handle);
return 0;
}


signature.asc
Description: PGP signature