Bug 89692
Summary: | dlopen()ed: static TLS memory too small | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Alan Hourihane <alanh> |
Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Brian Brock <bbrock> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 9 | CC: | fweimer, martin |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-08-04 20:20:36 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Alan Hourihane
2003-04-25 23:58:47 UTC
I've checked in a patch in the official glibc CVS archive. The change will be in the next build. Please try it. I don't use that proprietary code so I cannot check that specific case myself. Where do I get it ? I'm using rhn - when will it appear there ? Bug still present (in some form) in glibc-2.3.2-71. I have RH9 + updates + latest rawhide (via apt). Using nvidia's latest drivers I have a similar problem: ---XFree86 log (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so dlopen: /usr/X11R6/lib/modules/extensions/libglx.so: cannot allocate memory in static TLS block --- Using Alan's test case program already mentioned above, I can reproduce the problem: --- [martin@earth tmp]$ ./glibctest Opening libGL, try 0 Error: /usr/lib/tls/libGL.so: cannot allocate memory in static TLS block Segmentation fault (core dumped) --- Is there a workaround? That would be awesome so I could use opengl (no games right now). It would be also cool to get this fixed without having to downgrade off of the rawhide glibc. If this won't be fixed for a while and there is no workaround that's what I'll have to do (shudder). Works for me. rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' glibc glibc-2.3.2-71.i686 unless you have LD_ASSUME_KERNEL= <= 2.4.19 in the environment. Either use NPTL and TLS libGL, or use linuxthreads and non-TLS libGL. Interesting. Definitely doesn't work for me with your version of glibc and my custom kernel: --- 'uname -r' = "2.4.21smp-lowlat-pre-dvd" [martin@earth tmp]$ rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' glibc glibc-2.3.2-71.i686 --- But I found a workaround: If I define LD_ASSUME_KERNEL=2.4.21, it works! It appears with that defined, the linker chooses /lib/tls/libc.so.6 and /lib/tls/libm.so.6, which work. Otherwise, /lib/i686/libc.so.6 and /lib/i686/libm.so.6 are used, which *don't* work. I have run ldconfig as root multiple times. I can attach the output of 'ldconfig -v' in case it helps. Any pointers you can give to help me understand why is this happening are appreciated. Red Hat Linux and Red Hat Powertools are currently no longer supported by Red Hat, Inc. In an effort to clean up bugzilla, we are closing all bugs in MODIFIED state for these products. However, we do want to make sure that nothing important slips through the cracks. If, in fact, these issues are not resolved in a current Fedora Core Release (such as Fedora Core 5), please open a new issues stating so. Thanks. |