Launchpad has imported 35 comments from the remote bug at
https://bugzilla.redhat.com/show_bug.cgi?id=1124987.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
On 2014-07-30T19:22:15+00:00 Adam wrote:
Description of problem:
Crashes on startup in current F21.
Version-Release number of selected component:
calibre-1.46.0-1.fc21
Additional info:
reporter: libreport-2.2.3
cmdline:python2 /usr/bin/calibre --detach
executable: /usr/bin/calibre
kernel: 3.16.0-0.rc6.git2.2.fc22.x86_64
runlevel: N 5
type: Python
uid:1001
Truncated backtrace:
#1 in /usr/lib64/calibre/calibre/utils/magick/__init__.py:14
#2 in /usr/lib64/calibre/calibre/db/backend.py:31
#3 in /usr/lib64/calibre/calibre/db/legacy.py:17
#4 in /usr/lib64/calibre/calibre/gui2/ui.py:26
#5 run_gui in /usr/lib64/calibre/calibre/gui2/main.py:320
#6 main in /usr/lib64/calibre/calibre/gui2/main.py:458
#7 in /usr/bin/calibre:20
Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/137/comments/0
On 2014-07-30T19:22:18+00:00 Adam wrote:
Created attachment 922690
File: backtrace
Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/137/comments/1
On 2014-07-30T19:22:19+00:00 Adam wrote:
Created attachment 922691
File: environ
Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/137/comments/2
On 2014-08-06T13:17:25+00:00 Colin wrote:
I suspect this is a glibc change. We're seeing the same error message
in an Anaconda environment from trying to dlopen(libgtk.so).
Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/137/comments/3
On 2014-08-06T13:20:12+00:00 Adam wrote:
So, let's CC the glibc maintainer (at least, the person to whom glibc
bugs appear currently to be assigned).
Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/137/comments/4
On 2014-08-08T12:41:54+00:00 Adam wrote:
Created attachment 925164
LD_DEBUG log from crash (requested by carlos)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/137/comments/5
On 2014-08-08T12:51:31+00:00 Carlos wrote:
Please get the list of all shared libraries loaded by python then run
`readelf -a -W` against all of them and dump that to a file. I want to
know which if the libraries is using static TLS.
The error you are seeing is not a bug in glibc. The dynamic loader has a
fixed amount of "super fast" static TLS for use by core libraries which
are always loaded and can use this static TLS. Normal libraries should
not be using static TLS and you should not be running out of static TLS,
those loaded libraries should be using dynamic TLS which has no limits
(not quite as fast as static TLS but still fast).
Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/137/comments/6
On 2014-08-08T13:30:38+00:00 Colin wrote:
This is a good post on the issue:
http://stackoverflow.com/questions/19268293/matlab-error-cannot-open-
with-static-tls
Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/137/comments/7
On 2014-08-08T13:32:52+00:00 Kevin wrote:
"Please get the list of all shared libraries loaded by python then run
`readelf -a -W` against all of them and dump that to a file."
Is there some easy way to get this list without parsing the strace
output?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/137/comments/8
On 2014-08-08T19:26:34+00:00 Adam wrote:
I thought it might be in the abrt data, but I don't see it in there at
least in an obvious way. I can do the parsing, I just didn't want to
embarrass myself doing it in my monkey way in front of carlos :P when I
have some privacy to pore over the 'cut' manpages without anyone seeing,
I'll get it done...
Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/137/comments/9
On 2014-08-09T07:20:38+00:00 Carlos wrote:
(In reply to Adam Williamson (Red Hat) from comment #9)
> I thought it might be in the abrt data, but I don't see it in there at least
> in an obvious way. I can do the parsin
