Glibc Install-symbolic-link Segmentation Fault

Date: Sun, 18 Oct 2015 19:44:16 +0200 On 2015-10-13 00:27, Segmentation fault wrote: Package: libc6 Version: 2.19-18+deb8u1 Severity: normal File: libc-2.19.so Dear Maintainer,. Reporter, please consider answering these questions, where appropriate. What led up to the situation?. What exactly did you do (or not do) that was effective (or ineffective)?. What was the outcome of this action?. What outcome did you expect instead?The error message you report likely means that one of the libc functionswas wrongly passed a NULL pointer. As such it's a bug in the applicationyou used and not in the libc.

• Segmentation Fault Mac
• Glibc Install-symbolic-link Segmentation Fault System

Can you please consider answering theabove question, so that we can identify the broken application andreassign the bug to it? In the contrary we'll simply close this bug inthe next days.Aurelien-Aurelien Jarno GPG: 4096R/1DDD8C9Baurelien@aurel32.net.

Bug archived.Request was from Debbugs Internal Request to internalcontrol@bugs.debian.org.(Mon, 16 Nov 2015 07:30:32 GMT) (, ).Send a report that.Debian bug tracking system administrator.Last modified:Sun Dec 22 00:;Machine Name:buxtehudeDebbugs is free software and licensed under the terms of the GNUPublic License version 2. The current version can be obtainedfrom.Copyright © 1999 Darren O. Benham,1997,2003 nCipher Corporation Ltd,1994-97 Ian Jackson,2005-2017 Don Armstrong, and many other contributors.

Marius Heuler2009-09-17 12:31:27 UTCThe segmentation fault happens on different addresses below thenssfilesgethostbyname4r. Marius Heuler2009-09-17 13:47:45 UTCOk, thank you for that information!My problem with dynamic linking on a new linux system e.g.

Using glibc-2.11 thebinary won't start on older linux, it says: /lib64/libc.so.6: version`GLIBC2.7' not found. The application does not need any functions of that newlibrary, it would work fine with e.g. Is there a way to change theminimum dependency of the library?

It works when I compile on an old linuxsystem, it will run on new systems.When compiling the application on windows I can define the minimum neededversion in a define and then I can only uses functions available at that versionand not newer functions. Can this be done with glibc, that the binary stillworks with libraries definine e.g. GLIBC2.6?Thank you very much for helper so far!Marius. Marius Heuler2009-10-30 14:53:03 UTCHello!I included the whole pbthread:Using '-static -lpthread' or '-static /usr/lib64/libpthread.a' creates the samebinary. The lib pthread is also used by our code so should be included in thebinary.But the binary create like above still has the problems!Our solution is to link libc, libm and libpthread dynamic on a Ubuntu LTS 8.0.4system.

This binary works also on most other systems (with reasonable new glibc).On strange thing is: if I compile dynamic the same on a Fedora 7 system and runit on e.g. SLES 10 the binary breaks already in the loader with FloatingException. The binary compiled on Unbuntu with the same setup works fine. Thatis strange (probable SLES has no standard glibc). Greg Alexander2009-11-19 15:18:12 UTCI have not bothered to actually trace this but I have a likely suspect.As I understand it, resolution is handled by libnss.so, which are stilldynamically linked even if the executable is statically linked. Theypresumably feature weak extern references to various pthread functions.If pthreoads is dynamically linked, these references succeed.

Ifpthreads is statically linked then the pthread symbols are not reexportedto things loaded with dlopen like the libnss libraries.I don't know a good solution but perhaps -rdynamic has some role to play?Or perhaps a less bloated libc than glibc could be used, one which has anumber of simple resolvers built in? The libnss resolvers on my Linuxsystem take up 275kB which is enough space for many other unixes toimplement an entire libc. Jakabosky2011-03-26 07:36:11 UTCI first ran into this problem when using a Lua C module (ZeroMQ bindings for Lua) that uses IO threads in the background. The only work-around is to either compile the Lua VM with -pthread (This shouldn't be required, since not all Lua scripts need pthread support) or to use 'LDPRELOAD=/lib/libpthread.so hostprogram'.I would prefer an option where the host program (Lua VM) didn't have to either be compiled with -pthread or wrapped in a script to preload libpthread.so.Also the example program will even crash on a single-cpu(single-core) computer running Debian 6.0, glibc 2.11.2.

Carlos O'Donell2013-11-26 23:02:49 UTCIn a test case where the application doesn't link against libpthread, but a dlopen'd library does, parallel calls to getaddrinfo cause corruption in the IO layers and eventually a crash.Even though libpthread.so.1 has been loaded the weak-ref-and-check idiom in the NSS code isn't working. The GOT entry stays zero and therefore the nss code skips doing any locking and we get serious corruption via getcontents-GIfgetsunlocked (doing unlocked file IO with multiple threads causes data races and corruption).The skipped locks are in nssfilesgethostbyname4r (libnssfiles.so). When the application is compiled with -lpthread the GOT entry has a non-zero value of 0x00007ffff77bc460 which is '0x7ffff77bc460:sub $0x8,%rsp' and therefore correct. That entry is the GOT entry #40 with relocation: 20bfd8 000006 RX8664GLOBDAT 000000 pthreadmutexlock + 0.If libpthread is loaded.after. libnssfiles.so is loaded I don't see that there is anything you can do to make the NSS code use locks since the GOT relocation has already been processed. Carlos O'Donell2013-11-27 05:04:03 UTC(In reply to Rich Felker from ) Why is getaddrinfo trying to 'optimize' out the locking for single-threaded programs anyway? Certainly the time spent in getaddrinfo is dominated by actual lookups, not by locking overhead.I can only assume it does this to avoid requiring libpthread.

The actual lookups might also be very fast if they are resolved by /etc/hosts or some other local file-based NSS backend. Requiring the thread library would have a non-zero impact on performance for single-threaded applications. What other reason could there be for using the weak-ref-and-check idiom (which I know you don't like)? Rich Felker2013-11-27 05:19:17 UTCAs long as libpthread is a separate DSO, avoiding loading it makes sense, yes. However it seems that all the internal locking in glibc components (including nss modules) could be done with lock functions available unconditionally in libc rather than needing the pthread lock functions. I'm not familiar enough with the glibc internals to know whether such functions are already available, but it would certainly make for a cleaner solution to this and many other problems if they are. Note that the locking requirements for internal use are much simpler than pthread requirements; there are no difficult issues like different mutex types, self-synchronized destruction, etc.

Segmentation Fault Mac

Carlos O'Donell2013-11-27 05:29:26 UTC(In reply to Rich Felker from ) As long as libpthread is a separate DSO, avoiding loading it makes sense, yes. However it seems that all the internal locking in glibc components (including nss modules) could be done with lock functions available unconditionally in libc rather than needing the pthread lock functions. I'm not familiar enough with the glibc internals to know whether such functions are already available, but it would certainly make for a cleaner solution to this and many other problems if they are. Note that the locking requirements for internal use are much simpler than pthread requirements; there are no difficult issues like different mutex types, self-synchronized destruction, etc.No, you make a good point, and internally glibc already uses just plain futexes for libclocklock, but for non-libc modules like libnssfiles.so.2 (loaded as part of the NSS plugin mechanism) the libclocklock defines redirect to pthreadmutexlock. I see no reason at the moment why they couldn't just use futexes for serializing threaded access.

Glibc Install-symbolic-link Segmentation Fault System

There was certainly no futex support when these NSS modules were written so it might be a legacy issue. Switching them over to futex locking would solve this problem and the uncontended lock case is an atomic operation that should always succeeds. Horst Schirmeier2017-08-17 16:17:13 UTCThis bug is still reproducible in 2.23(-r4, Gentoo) and 2.24(-9ubuntu2.2, Ubuntu 17.04).What I really don't get is that it even crashes if I protect calls to gethostbyname with a pthread mutex.