Bug#808180: Re[2]: Bug#808180: libc6: does not start qtcreator v3.5 and v3.6 "Segmentation fault."
$ gdb qtcreator .. (gdb) run Starting program: /home/lukash/Qt5.5.1/Tools/QtCreator/bin/qtcreator [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffec5cb700 (LWP 14948)] [New Thread 0x7fffd8422700 (LWP 14951)] Program received signal SIGSEGV, Segmentation fault. 0x77de69ab in elf_machine_rela (reloc=0x7fffdcf41548, reloc=0x7fffdcf41548, skip_ifunc=0, reloc_addr_arg=0x7fffdd291ef0, version=0x30, sym=0x7fffdcf191d8, map=0x723350) at ../sysdeps/x86_64/dl-machine.h:277 277 ../sysdeps/x86_64/dl-machine.h: No such file or directory. (gdb) backtrace #0 0x77de69ab in elf_machine_rela (reloc=0x7fffdcf41548, reloc=0x7fffdcf41548, skip_ifunc=0, reloc_addr_arg=0x7fffdd291ef0, version=0x30, sym=0x7fffdcf191d8, map=0x723350) at ../sysdeps/x86_64/dl-machine.h:277 #1 elf_dynamic_do_Rela (skip_ifunc=0, lazy=, nrelative=, relsize=, reladdr=, map=0x723350) at do-rel.h:137 #2 _dl_relocate_object (scope=, reloc_mode=reloc_mode@entry=0, consider_profiling=, consider_profiling@entry=0) at dl-reloc.c:258 #3 0x77dee831 in dl_open_worker (a=a@entry=0x7fffcfe8) at dl-open.c:429 #4 0x77dea114 in _dl_catch_error (objname=objname@entry=0x7fffcfd8, errstring=errstring@entry=0x7fffcfe0, mallocedp=mallocedp@entry=0x7fffcfd7, operate=operate@entry=0x77dee4e0 , args=args@entry=0x7fffcfe8) at dl-error.c:187 #5 0x77dedf63 in _dl_open (file=0x756930ab "libGL.so.1", mode=-2147483390, caller_dlopen=0x7565d308, nsid=-2, argc=, argv=, env=0x7fffe1f8) at dl-open.c:653 #6 0x745c0f09 in dlopen_doit (a=a@entry=0x7fffd200) at dlopen.c:66 #7 0x77dea114 in _dl_catch_error (objname=0x634980, errstring=0x634988, mallocedp=0x634978, operate=0x745c0eb0 , args=0x7fffd200) at dl-error.c:187 #8 0x745c14d9 in _dlerror_run (operate=operate@entry=0x745c0eb0 , args=args@entry=0x7fffd200) at dlerror.c:163 #9 0x745c0fa1 in __dlopen (file=, mode=) at dlopen.c:87 #10 0x7565d308 in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1 #11 0x75660275 in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1 #12 0x756388c4 in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1 #13 0x756346b7 in glXGetFBConfigs () from /usr/lib/x86_64-linux-gnu/libGL.so.1 #14 0x75635972 in glXChooseFBConfigSGIX () from /usr/lib/x86_64-linux-gnu/libGL.so.1 #15 0x7fffeb9bc86e in ?? () from /home/lukash/Qt5.5.1/Tools/QtCreator/lib/Qt/plugins/xcbglintegrations/libqxcb-glx-integration.so #16 0x7fffeb9b9ab2 in ?? () from /home/lukash/Qt5.5.1/Tools/QtCreator/lib/Qt/plugins/xcbglintegrations/libqxcb-glx-integration.so #17 0x7fffeb9b873b in ?? () from /home/lukash/Qt5.5.1/Tools/QtCreator/lib/Qt/plugins/xcbglintegrations/libqxcb-glx-integration.so #18 0x7fffedc09a71 in QXcbIntegration::createPlatformOpenGLContext(QOpenGLContext*) const () from /home/lukash/Qt5.5.1/Tools/QtCreator/lib/Qt/plugins/platforms/../../lib/libQt5XcbQpa.so.5 #19 0x766876ed in QOpenGLContext::create() () from /home/lukash/Qt5.5.1/Tools/QtCreator/bin/../lib/Qt/lib/libQt5Gui.so.5 #20 0x776fa495 in Utils::HostOsInfo::canCreateOpenGLContext(QString*) () from /home/lukash/Qt5.5.1/Tools/QtCreator/bin/../lib/qtcreator/libUtils.so.1 #21 0x7fffdd53ae4c in QmlDesigner::QmlDesignerPlugin::initialize(QStringList const&, QString*) () from /home/lukash/Qt5.5.1/Tools/QtCreator/lib/qtcreator/plugins/libQmlDesigner.so #22 0x77bbd006 in ExtensionSystem::Internal::PluginSpecPrivate::initializePlugin() () from /home/lukash/Qt5.5.1/Tools/QtCreator/bin/../lib/qtcreator/libExtensionSystem.so.1 #23 0x77bb52df in ExtensionSystem::Internal::PluginManagerPrivate::loadPlugin(ExtensionSystem::PluginSpec*, ExtensionSystem::PluginSp ec::State) () from /home/lukash/Qt5.5.1/Tools/QtCreator/bin/../lib/qtcreator/libExtensionSystem.so.1 #24 0x77bb7670 in ExtensionSystem::Internal::PluginManagerPrivate::loadPlugins() () from /home/lukash/Qt5.5.1/Tools/QtCreator/bin/../lib/qtcreator/libExtensionSystem.so.1 #25 0x00409b40 in ?? () #26 0x747e4870 in __libc_start_main (main=0x406
Re: Fixing the armhf linker path
On Thu, Dec 17, 2015 at 11:04:47AM +, Steve McIntyre wrote: >On Wed, Dec 16, 2015 at 11:30:53PM +0100, Aurelien Jarno wrote: >>At the beginning of the armhf port the hard-float dynamic linker has >>been chosen to be '/lib/arm-linux-gnueabihf/ld-linux.so.3'. However it >>has been standardized later as '/lib/ld-linux-armhf.so.3' [1]. We have >>changed it in Debian, and added a patch to the glibc [2] to temporarily >>support both paths, until all the packages have been rebuilt with the >>new path. >> >>However we failed to do it for Wheezy. We also failed to do it for >>Jessie. So let's do it for Stretch, so that we can drop the glibc >>patches in Buster, and ensure binary compatibility with other >>distributions. >> >>For that we first need to binNMU the packages which have not been >>rebuilt since the dynamic linker change in unstable (see the list at >>the end of the mail). Then we can have a look at getting all of them >>migrated to testing. >> >>Any comments or objections? > >ACK, this makes sense. I spoke with Adam a while back about doing >this. I promised I'd scan the archive for any packages still relying >on the old linker path, but I've not got to it yet - sorry. :-/ And I did today. Scanning all the armhf debs in stretch and sid for linker path suggests the following binary packages needing updating/rebuilding: stretch sid main 741 771 contrib 34 non-free 34 Logs of the found wrong linker paths (by binary package and binary) are attached. -- Steve McIntyre, Cambridge, UK.st...@einval.com Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ stretch-out-main.gz Description: application/gzip stretch-out-contrib.gz Description: application/gzip stretch-out-non-free.gz Description: application/gzip sid-out-main.gz Description: application/gzip sid-out-contrib.gz Description: application/gzip sid-out-non-free.gz Description: application/gzip
Upcoming stable point release (8.3)
Hi, The next point release for "jessie" (8.3) is scheduled for Saturday, January 23rd. Processing of new uploads into jessie-proposed-updates will be frozen during the preceding weekend. Regards, Adam
Bug#737079: marked as done (nscd crashes on netgroup lookups)
Your message dated Thu, 17 Dec 2015 23:07:42 +0100 with message-id <20151217220742.ga4...@aurel32.net> and subject line Re: Bug#737079: nscd crashes on netgroup lookups has caused the Debian Bug report #737079, regarding nscd crashes on netgroup lookups to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 737079: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737079 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: nscd Version: 2.17-97 Severity: important I can reasonably consistently crash nscd with netgroup lookups. Below is the simplest configuration I can reproduce this with: /etc/nsswitch.conf: netgroup: files /etc/netgroup : tst5netgroup(foo, , ) (bar, , ) tst6netgroup tst7netgroup tst7netgroup(baz, , ) (/etc/nscd.conf is attached, no /var/cache/nscd present) When running the following lookup nscd crashes. getent netgroup tst5netgroup tst5netgroup (foo,,) (bar,,) (baz,,) Attached is output of running nscd under valgrind with just the one lookup. I also built nscd from source (built 2.17-97, though not particularly clean build environment and used built source directory to run nscd) to get the debug symbols included. Attached also valgrind and gdb output from the crashes with this version also. Thanks, -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nscd depends on: ii libaudit11:2.3.3-3 ii libc62.17-97 ii libcap2 1:2.22-1.2 ii libselinux1 2.2.2-1 -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- # # /etc/nscd.conf # # An example Name Service Cache config file. This file is needed by nscd. # # Legal entries are: # # logfile # debug-level # threads # max-threads # server-user # server-user is ignored if nscd is started with -S parameters # stat-user # reload-countunlimited| # paranoia # restart-interval # # enable-cache # positive-time-to-live # negative-time-to-live # suggested-size # check-files # persistent # shared # max-db-size # auto-propagate # # Currently supported cache names (services): passwd, group, hosts, services # # logfile /var/log/nscd.log # threads 4 # max-threads 32 # server-user nobody # stat-user somebody debug-level 0 # reload-count5 paranoiano # restart-interval3600 enable-cachepasswd yes positive-time-to-live passwd 600 negative-time-to-live passwd 20 suggested-size passwd 211 check-files passwd yes persistent passwd yes shared passwd yes max-db-size passwd 33554432 auto-propagate passwd yes enable-cachegroup yes positive-time-to-live group 3600 negative-time-to-live group 60 suggested-size group 211 check-files group yes persistent group yes shared group yes max-db-size group 33554432 auto-propagate group yes enable-cachehosts yes positive-time-to-live hosts 3600 negative-time-to-live hosts 20 suggested-size hosts 211 check-files hosts yes persistent hosts yes shared hosts yes max-db-size hosts 33554432 enable-cacheservicesyes positive-time-to-live services28800 negative-time-to-live services20 sugge
Bug#808180: Re[2]: Bug#808180: libc6: does not start qtcreator v3.5 and v3.6 "Segmentation fault."
libc6-dbg amd64 2.21-4 $ gdb qtcreator . Reading symbols from qtcreator...(no debugging symbols found)...done. (gdb) run Starting program: /home/lukash/Qt5.5.1/Tools/QtCreator/bin/qtcreator [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffec5cb700 (LWP 5363)] [New Thread 0x7fffd832c700 (LWP 5366)] Program received signal SIGSEGV, Segmentation fault. 0x77de69ab in elf_machine_rela (reloc=0x7fffdcf41548, reloc=0x7fffdcf41548, skip_ifunc=0, reloc_addr_arg=0x7fffdd291ef0, version=0x30, sym=0x7fffdcf191d8, map=0x722f30) at ../sysdeps/x86_64/dl-machine.h:277 277 ../sysdeps/x86_64/dl-machine.h: No such file or directory. -- Антоша ;) >Среда, 16 декабря 2015, 22:23 +01:00 от Samuel Thibault : > >Hello, > >lukash, on Wed 16 Dec 2015 23:49:47 +0300, wrote: >> (gdb) run >> Starting program: ~/Qt5.5.1/Tools/QtCreator/bin/qtcreator >> [Thread debugging using libthread_db enabled] >> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". >> [New Thread 0x7fffec5cb700 (LWP 1282)] >> [New Thread 0x7fffd831b700 (LWP 1285)] >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x77de72c6 in ?? () from /lib64/ld-linux-x86-64.so.2 > >Could you install libc6-dbg so we get much better feedback from gdb? > >Thanks, >Samuel
Bug#808180: libc6: does not start qtcreator v3.5 and v3.6 "Segmentation fault."
Please always keep the bug mail in Cc, not just the random developper who happened to answer. "Антоша ;)", on Thu 17 Dec 2015 19:35:21 +0300, wrote: > $ gdb qtcreator > . > Reading symbols from qtcreator...(no debugging symbols found)...done. > (gdb) run > Starting program: /home/lukash/Qt5.5.1/Tools/QtCreator/bin/qtcreator > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > [New Thread 0x7fffec5cb700 (LWP 5363)] > [New Thread 0x7fffd832c700 (LWP 5366)] > > Program received signal SIGSEGV, Segmentation fault. > 0x77de69ab in elf_machine_rela (reloc=0x7fffdcf41548, reloc= > 0x7fffdcf41548, skip_ifunc=0, reloc_addr_arg=0x7fffdd291ef0, > version=0x30, sym=0x7fffdcf191d8, map=0x722f30) at ../sysdeps/x86_64/ > dl-machine.h:277 > 277 ../sysdeps/x86_64/dl-machine.h: No such file or directory. Please provide the result of the backtrace command in gdb too. Samuel
r6824 - in glibc-package/branches/glibc-branch-jessie/debian: . patches patches/any
Author: aurel32 Date: 2015-12-17 18:45:34 + (Thu, 17 Dec 2015) New Revision: 6824 Added: glibc-package/branches/glibc-branch-jessie/debian/patches/any/cvs-strxfrm-buffer-overflows.diff Modified: glibc-package/branches/glibc-branch-jessie/debian/changelog glibc-package/branches/glibc-branch-jessie/debian/patches/series Log: patches/any/cvs-strxfrm-buffer-overflows.diff: new patch from upstream to fix memory allocations issues that can lead to buffer overflows on the stack. Closes: #803927. Modified: glibc-package/branches/glibc-branch-jessie/debian/changelog === --- glibc-package/branches/glibc-branch-jessie/debian/changelog 2015-12-15 23:00:10 UTC (rev 6823) +++ glibc-package/branches/glibc-branch-jessie/debian/changelog 2015-12-17 18:45:34 UTC (rev 6824) @@ -14,6 +14,9 @@ unconditionally disable LD_POINTER_GUARD. Closes: #798316, #801691. * patches/any/cvs-mangle-tls_dtor_list.diff: new patch from upstream to mangle function pointers in tls_dtor_list. Closes: #802256. + * patches/any/cvs-strxfrm-buffer-overflows.diff: new patch from upstream +to fix memory allocations issues that can lead to buffer overflows on +the stack. Closes: #803927. [ Henrique de Moraes Holschuh ] * Replace patches/amd64/local-blacklist-on-TSX-Haswell.diff by Added: glibc-package/branches/glibc-branch-jessie/debian/patches/any/cvs-strxfrm-buffer-overflows.diff === --- glibc-package/branches/glibc-branch-jessie/debian/patches/any/cvs-strxfrm-buffer-overflows.diff (rev 0) +++ glibc-package/branches/glibc-branch-jessie/debian/patches/any/cvs-strxfrm-buffer-overflows.diff 2015-12-17 18:45:34 UTC (rev 6824) @@ -0,0 +1,670 @@ +2015-01-13 Leonhard Holz + + [BZ #16009] + * string/strxfrm_l.c (STRXFRM): Allocate fixed size cache for + weights and rules. Use do_xfrm_cached if data fits in cache, + do_xfrm otherwise. Moved former main loop to... + * (do_xfrm_cached): New function. + * (do_xfrm): Non-caching version of do_xfrm_cached. Uses + find_idx, find_position and stack_push. + * (find_idx): New function. + * (find_position): Likewise. + * localedata/sort-test.sh: Added test run for do_xfrm. + * localedata/xfrm-test.c (main): Added command line option + -nocache to run the test with strings that are too large for + the STRXFRM cache. + +--- a/localedata/sort-test.sh b/localedata/sort-test.sh +@@ -49,11 +49,17 @@ +${common_objpfx}localedata/xfrm-test $id < $cns.in \ +> ${common_objpfx}localedata/$cns.xout || here=1 + cmp -s $cns.in ${common_objpfx}localedata/$cns.xout || here=1 ++ LOCPATH=${common_objpfx}localedata GCONV_PATH=${common_objpfx}/iconvdata \ ++ LC_ALL=$l ${run_program_prefix} \ ++ ${common_objpfx}localedata/xfrm-test $id -nocache < $cns.in \ ++ > ${common_objpfx}localedata/$cns.nocache.xout || here=1 ++ cmp -s $cns.in ${common_objpfx}localedata/$cns.nocache.xout || here=1 + if test $here -eq 0; then + echo "$l xfrm-test OK" + else + echo "$l xfrm-test FAIL" + diff -u $cns.in ${common_objpfx}localedata/$cns.xout | sed 's/^/ /' ++diff -u $cns.in ${common_objpfx}localedata/$cns.nocache.xout | sed 's/^/ /' + status=1 + fi + done +--- a/localedata/xfrm-test.c b/localedata/xfrm-test.c +@@ -23,7 +23,10 @@ + #include + #include + #include ++#include + ++/* Keep in sync with string/strxfrm_l.c. */ ++#define SMALL_STR_SIZE 4095 + + struct lines + { +@@ -37,6 +40,7 @@ + main (int argc, char *argv[]) + { + int result = 0; ++ bool nocache = false; + size_t nstrings, nstrings_max; + struct lines *strings; + char *line = NULL; +@@ -44,7 +48,18 @@ + size_t n; + + if (argc < 2) +-error (1, 0, "usage: %s ", argv[0]); ++error (1, 0, "usage: %s [-nocache]", argv[0]); ++ ++ if (argc == 3) ++{ ++ if (strcmp (argv[2], "-nocache") == 0) ++ nocache = true; ++ else ++ { ++printf ("Unknown option %s!\n", argv[2]); ++exit (1); ++ } ++} + + setlocale (LC_ALL, ""); + +@@ -59,9 +74,9 @@ + + while (1) + { +- char saved, *newp; +- int needed; +- int l; ++ char saved, *word, *newp; ++ size_t l, line_len, needed; ++ + if (getline (&line, &len, stdin) < 0) + break; + +@@ -83,10 +98,35 @@ + + saved = line[l]; + line[l] = '\0'; +- needed = strxfrm (NULL, line, 0); ++ ++ if (nocache) ++ { ++line_len = strlen (line); ++word = malloc (line_len + SMALL_STR_SIZE + 1); ++if (word == NULL) ++ { ++printf ("malloc failed: %m\n"); ++exit (1); ++ } ++memset (word, ' ', SMALL_STR_SIZE); ++memcpy (word + SMALL_STR_SIZE, line, line_len); ++word[line_len + SMALL_STR_SIZE] = '\0'; ++
Bug#760902: marked as done (libc6: ld-linux-x86-64.so.2 segfaults with LD_BIND_NOW=yes on some binaries generated by golang)
Your message dated Thu, 17 Dec 2015 19:48:20 +0100 with message-id <20151217184820.ga15...@aurel32.net> and subject line Bug#710521: "ldd -r /usr/bin/go" segfaults has caused the Debian Bug report #710521, regarding libc6: ld-linux-x86-64.so.2 segfaults with LD_BIND_NOW=yes on some binaries generated by golang to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 710521: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710521 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: aptly Version: 0.5-4 Severity: normal Dear Maintainer, I was curious about aptly and hence installed it. While installing it came across the following :- $ sudo aptitude install aptly The following NEW packages will be installed: aptly 0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 1,703 kB of archives. After unpacking 9,068 kB will be used. Get: 1 http://debian.ec.as6453.net/debian/ unstable/main aptly amd64 0.5-4 [1,703 kB] Fetched 1,703 kB in 48s (35.1 kB/s) Retrieving bug reports... Done Parsing Found/Fixed information... Done D01: ensure_diversions: new, (re)loading D01: ensure_statoverrides: new, (re)loading Selecting previously unselected package aptly. (Reading database ... 561585 files and directories currently installed.) Preparing to unpack .../archives/aptly_0.5-4_amd64.deb ... D01: process_archive oldversionstatus=not installed Unpacking aptly (0.5-4) ... D01: process_archive updating info directory D01: generating infodb hashfile Processing triggers for debian-security-support (2014.07.31) ... D01: cmpversions a='0:1.17.13' b='0:1.16' r=1 D01: cmpversions a='0:1.17.13' b='0:1.16' r=1 D01: ensure_diversions: same, skipping Processing triggers for man-db (2.6.7.1-1) ... D01: ensure_diversions: same, skipping D01: ensure_diversions: new, (re)loading Setting up aptly (0.5-4) ... D01: deferred_configure updating conffiles ldd -r: failed at /usr/bin/adequate line 812, <$ldd> line 4. E: Problem executing scripts DPkg::Post-Invoke 'adequate --help >/dev/null 2>&1 || exit 0; DEBIAN_FRONTEND=readline exec adequate --debconf --user nobody --pending' E: Sub-process returned an error code Failed to perform requested operation on package. Trying to recover: D01: ensure_diversions: new, (re)loading The relevant error seems to be at ldd -r: failed at /usr/bin/adequate line 812, <$ldd> line 4. E: Problem executing scripts DPkg::Post-Invoke 'adequate --help >/dev/null 2>&1 || exit 0; DEBIAN_FRONTEND=readline exec adequate --debconf --user nobody --pending' E: Sub-process returned an error code Failed to perform requested operation on package. Trying to recover: D01: ensure_diversions: new, (re)loading I use adequate to figure out issues with packages and those options help make sure that the errors are known without my screen glowing and things like that. Please let me know if any more information is needed from my end. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (600, 'testing'), (500, 'testing-updates'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages aptly depends on: ii libc6 2.19-10 aptly recommends no packages. aptly suggests no packages. -- no debconf information -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8 --- End Message --- --- Begin Message --- Version: eglibc/2.19-1 On 2013-05-31 17:35, Jakub Wilk wrote: > Package: libc6 > Version: 2.17-3 > > Running "ldd -r" on /usr/bin/go (shipped by golang-go 2:1.1-1) causes a > segfault: > > $ ldd -r /usr/bin/go > linux-gate.so.1 (0xf7757000) > libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7738000) > libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf75c3000) > /lib/ld-linux.so.2 (0xf7758000) > /usr/bin/ldd: line 116: 8528 Segmentation fault > LD_TRACE_LOADED_OBJECTS=1 LD_WARN=yes LD_BIND_NOW=yes > LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= "$@" I can reproduce the problem with eglibc 2.18-4, but not with 2.19-1 and later versions. I therefore believe the problem has been fixed and I am closing the bug with this mail. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net
Bug#710521: marked as done ("ldd -r /usr/bin/go" segfaults)
Your message dated Thu, 17 Dec 2015 19:48:20 +0100 with message-id <20151217184820.ga15...@aurel32.net> and subject line Bug#710521: "ldd -r /usr/bin/go" segfaults has caused the Debian Bug report #710521, regarding "ldd -r /usr/bin/go" segfaults to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 710521: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710521 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6 Version: 2.17-3 Running "ldd -r" on /usr/bin/go (shipped by golang-go 2:1.1-1) causes a segfault: $ ldd -r /usr/bin/go linux-gate.so.1 (0xf7757000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7738000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf75c3000) /lib/ld-linux.so.2 (0xf7758000) /usr/bin/ldd: line 116: 8528 Segmentation fault LD_TRACE_LOADED_OBJECTS=1 LD_WARN=yes LD_BIND_NOW=yes LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= "$@" -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.8-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii libgcc1 1:4.8.0-9 Versions of packages libc6 recommends: pn libc6-i686 Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.50 pn glibc-doc pn locales -- Jakub Wilk --- End Message --- --- Begin Message --- Version: eglibc/2.19-1 On 2013-05-31 17:35, Jakub Wilk wrote: > Package: libc6 > Version: 2.17-3 > > Running "ldd -r" on /usr/bin/go (shipped by golang-go 2:1.1-1) causes a > segfault: > > $ ldd -r /usr/bin/go > linux-gate.so.1 (0xf7757000) > libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7738000) > libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf75c3000) > /lib/ld-linux.so.2 (0xf7758000) > /usr/bin/ldd: line 116: 8528 Segmentation fault > LD_TRACE_LOADED_OBJECTS=1 LD_WARN=yes LD_BIND_NOW=yes > LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= "$@" I can reproduce the problem with eglibc 2.18-4, but not with 2.19-1 and later versions. I therefore believe the problem has been fixed and I am closing the bug with this mail. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net--- End Message ---
Bug#510819: marked as done (libc6: printf incorrectly shows argument with value 0 on conversion %#04hhx and related)
Your message dated Thu, 17 Dec 2015 19:47:58 +0100 with message-id <20151217184758.ga20...@aurel32.net> and subject line Re: Bug#510819: libc6: printf incorrectly shows argument with value 0 on conversion %#04hhx and related has caused the Debian Bug report #510819, regarding libc6: printf incorrectly shows argument with value 0 on conversion %#04hhx and related to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 510819: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510819 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6 Version: 2.7-16 Severity: normal Conversion %#04hhx in printf means "convert the argument to a uint8_t (hh) and show it as an hexadecimal number (x) with leading zeros if necessary (0) and a leading 0x prefix (#) in a field of total lenght four (4), that is, two places for 0x and two for the argument value". If the argument is 0 the expected behaviour is to show 0x00 but it shows With other arguments it works ok. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libc6 depends on: ii libgcc1 1:4.3.2-1 GCC support library libc6 recommends no packages. Versions of packages libc6 suggests: ii glibc-doc 2.7-16 GNU C Library: Documentation ii libc6-i6862.7-16 GNU C Library: Shared libraries [i ii locales 2.7-16 GNU C Library: National Language ( -- debconf information: glibc/upgrade: true glibc/restart-failed: glibc/restart-services: --- End Message --- --- Begin Message --- On 2009-01-05 04:50, Noel David Torres Taño wrote: > Package: libc6 > Version: 2.7-16 > Severity: normal > > > Conversion %#04hhx in printf means "convert the argument to a uint8_t (hh) > and show it as an hexadecimal number (x) with leading zeros if necessary (0) > and a leading 0x prefix (#) in a field of > total lenght four (4), that is, two places for 0x and two for the argument > value". > > If the argument is 0 the expected behaviour is to show 0x00 but it shows > > With other arguments it works ok. printf has the correct behaviour as the value 0 is a special case. Quoting POSIX [1]: | # | Specifies that the value is to be converted to an alternative form. | For o conversion, it increases the precision (if necessary) to force | the first digit of the result to be zero. For x or X conversion | specifiers, a non-zero result shall have 0x (or 0X) prefixed to it. | For a, A, e, E, f, F, g , and G conversion specifiers, the result | shall always contain a radix character, even if no digits follow the | radix character. Without this flag, a radix character appears in the | result of these conversions only if a digit follows it. For g and G | conversion specifiers, trailing zeros shall not be removed from the | result as they normally are. For other conversion specifiers, the | behavior is undefined. | 0. As you can see the '0x' prefix is added only for a non-zero value. That is why '' is the correct output here. I am therefore closing the bug. [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net--- End Message ---
Bug#699321: marked as done (libc6: statvfs() calling stat() unnecessarily (2.6.36))
Your message dated Thu, 17 Dec 2015 19:47:29 +0100 with message-id <20151217184729.ga16...@aurel32.net> and subject line Re: Bug#699321: libc6: statvfs() calling stat() unnecessarily (2.6.36) has caused the Debian Bug report #699321, regarding libc6: statvfs() calling stat() unnecessarily (2.6.36) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 699321: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699321 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6 Version: 2.13-37 Severity: normal Running statvfs() my machine still results in stat() being called, and from what I can tell, it's being called _before_ __statvfs_getflags() is called. I have not yet determined where stat() is called, but strace on my C program (see below) confirms stat() is called after statfs(), but before the fprintf() I added in sysdeps/unix/sysv/linux/internal_statvfs.c: /* * I added the following fprintf() in my local build and confirmed * ST_VALID (0x20) is set here by my 3.7.5 kernel: */ fprintf(stderr, "f_flags: 0x%lx\n", fsbuf->f_flags); #ifndef __ASSUME_STATFS_F_FLAGS if ((fsbuf->f_flags & ST_VALID) == 0) /* Determining the flags is tricky. We have to read /proc/mounts or the /etc/mtab file and search for the entry which matches the given file. The way we can test for matching filesystem is using the device number. */ buf->f_flag = __statvfs_getflags (name, fsbuf->f_type, st); else #endif buf->f_flag = fsbuf->f_flags ^ ST_VALID; Here is my trivial C program I straced to confirm stat() being called after statfs(): /* gcc -o statvfs -Wall statvfs.c */ #include int main(void) { struct statvfs svf; statvfs("/mnt", &svf); return 0; } I do not expect stat() to be called with statvfs(), since ST_VALID helps avoid this expensive check. stat() also has detrimental effects on unreachable/slow network mounts. -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.7.5 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii libc-bin 2.13-37 ii libgcc1 1:4.7.2-5 libc6 recommends no packages. Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.49 ii glibc-doc 2.13-37 ii locales2.13-37 -- debconf information excluded --- End Message --- --- Begin Message --- Version: 2.21-1 On 2013-01-30 08:33, Eric Wong wrote: > Package: libc6 > Version: 2.13-37 > Severity: normal > > Running statvfs() my machine still results in stat() being called, and from > what I can tell, it's being called _before_ __statvfs_getflags() is called. > I > have not yet determined where stat() is called, but strace on my C program > (see > below) confirms stat() is called after statfs(), but before the fprintf() I > added in sysdeps/unix/sysv/linux/internal_statvfs.c: > > /* >* I added the following fprintf() in my local build and confirmed >* ST_VALID (0x20) is set here by my 3.7.5 kernel: >*/ >fprintf(stderr, "f_flags: 0x%lx\n", fsbuf->f_flags); > > #ifndef __ASSUME_STATFS_F_FLAGS > if ((fsbuf->f_flags & ST_VALID) == 0) > /* Determining the flags is tricky. We have to read /proc/mounts or >the /etc/mtab file and search for the entry which matches the given >file. The way we can test for matching filesystem is using the >device number. */ > buf->f_flag = __statvfs_getflags (name, fsbuf->f_type, st); > else > #endif > buf->f_flag = fsbuf->f_flags ^ ST_VALID; > > Here is my trivial C program I straced to confirm stat() being called > after statfs(): > > /* gcc -o statvfs -Wall statvfs.c */ > #include > int main(void) > { > struct statvfs svf; > statvfs("/mnt", &svf); > return 0; > } > > > I do not expect stat() to be called with statvfs(), since ST_VALID helps > avoid this expensive check. stat() also has detrimental effects on > unreachable/slow network mounts. This bug has been fixed in glibc version 2.20. I am therefore closing the bug. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net--- End Message --
Bug#687545: marked as done (libc6: Incorrect decimal printf output of tiny long double values on PowerPC)
Your message dated Thu, 17 Dec 2015 19:47:53 +0100 with message-id <20151217184753.ga17...@aurel32.net> and subject line Re: Bug#687545: libc6: Incorrect decimal printf output of tiny long double values on PowerPC has caused the Debian Bug report #687545, regarding libc6: Incorrect decimal printf output of tiny long double values on PowerPC to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 687545: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687545 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6 Version: 2.13-35 Severity: normal The minimum positive long double value is not output correctly by printf with the decimal conversion specifiers (e, f, g) on PowerPC (where long double is implemented with a double-double arithmetic). See the testcase below. There may be the same problem with other tiny values. #include #include int main (void) { double d; long double e; d = nextafter (0.0, 1.0); printf ("d = %e = %f = %g = %a\n", d, d, d, d); e = d; printf ("e = %Le = %Lf = %Lg = %La\n", e, e, e, e); d = e; printf ("d = %e = %f = %g = %a\n", d, d, d, d); printf ("d = %.330f\n", d); printf ("e = %.330Lf\n", e); return 0; } I get: d = 4.940656e-324 = 0.00 = 4.94066e-324 = 0x0.1p-1022 e = 4.450148e-308 = 0.00 = 4.45015e-308 = 0x0.1p-1022 d = 4.940656e-324 = 0.00 = 4.94066e-324 = 0x0.1p-1022 d = 0.0004940656 e = 0.00044501477170144027661805 Note that 4.450148e-308 / 4.940656e-324 is about 2^53, where 53 is the precision of a double. I suspect that the glibc code doesn't handle small values such that one of the double's in the representation is 0. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (900, 'stable'), (200, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.26-1-powerpc Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libc6 depends on: ii libc-bin 2.13-35 ii libgcc1 1:4.7.1-7 libc6 recommends no packages. Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.46 pn glibc-doc ii locales2.13-35 -- debconf information: glibc/upgrade: true glibc/disable-screensaver: * glibc/restart-failed: * glibc/restart-services: spamassassin openbsd-inetd exim4 cron atd * libraries/restart-without-asking: true -- debsums errors found: dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 5250 package 'inn2': missing architecture dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 8462 package 'libgdbmg1': missing architecture dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 11058 package 'libnewt0': missing architecture dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 13393 package 'docbook-mathml': missing architecture dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 22784 package 'libpcd': missing architecture dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 31190 package 'inn2-inews': missing architecture dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 33324 package 'libisc4': missing architecture dpkg-divert: warning: parsing file '/var/lib/dpkg/status' near line 5250 package 'inn2': missing architecture dpkg-divert: warning: parsing file '/var/lib/dpkg/status' near line 8462 package 'libgdbmg1': missing architecture dpkg-divert: warning: parsing file '/var/lib/dpkg/status' near line 11058 package 'libnewt0': missing architecture dpkg-divert: warning: parsing file '/var/lib/dpkg/status' near line 13393 package 'docbook-mathml': missing architecture dpkg-divert: warning: parsing file '/var/lib/dpkg/status' near line 22784 package 'libpcd': missing architecture dpkg-divert: warning: parsing file '/var/lib/dpkg/status' near line 31190 package 'inn2-inews': missing arch
Bug#694964: marked as done (libc6:amd64: binary debian target fails - /usr/include/locale.h cannot be removed)
Your message dated Thu, 17 Dec 2015 19:47:39 +0100 with message-id <20151217184739.ga16...@aurel32.net> and subject line Re: Bug#694964: libc6:amd64: binary debian target fails - /usr/include/locale.h cannot be removed has caused the Debian Bug report #694964, regarding libc6:amd64: binary debian target fails - /usr/include/locale.h cannot be removed to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 694964: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694964 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6 Version: 2.16-0experimental1 Severity: normal Dear Maintainer, A local dpkg-buildpackage of the 2.16 package leads to this error: make[3]: Entering directory `/home/prahal/checkout/glibc6/eglibc-2.16/locale' /usr/bin/install -c -m 644 locale.h /usr/include/locale.h /usr/bin/install: cannot remove '/usr/include/locale.h': Permission denied make[3]: *** [/usr/include/locale.h] Error 1 make[3]: Leaving directory `/home/prahal/checkout/glibc6/eglibc-2.16/locale' make[2]: *** [locale/subdir_install] Error 2 make[2]: Leaving directory `/home/prahal/checkout/glibc6/eglibc-2.16' make[1]: *** [install] Erreur 2 make[1] : on quitte le répertoire « /home/prahal/checkout/glibc6/eglibc-2.16/build-tree/amd64-libc » make: *** [/home/prahal/checkout/glibc6/eglibc-2.16/stamp-dir/install_libc] Erreur 2 dpkg-buildpackage: erreur: fakeroot debian/rules binary a produit une erreur de sortie de type 2 It turns out the locale/Makefile is missing: include ../Makeconfig Attached patch fixes that issue. Regards, Alban -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.7.0-rc4test0-00020-g0e4a43e (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc6:amd64 depends on: ii debconf [debconf-2.0] 1.5.46 ii libgcc11:4.7.2-12 libc6:amd64 recommends no packages. Versions of packages libc6:amd64 suggests: pn glibc-doc pn locales -- debconf information: * glibc/upgrade: true glibc/disable-screensaver: glibc/restart-failed: * glibc/restart-services: spamassassin ssh saslauthd samba openbsd-inetd mysql exim4 cups cron atd apache2 * libraries/restart-without-asking: false --- locale/Makefile.orig 2012-12-02 19:28:18.071115539 +0100 +++ locale/Makefile 2012-12-02 10:45:54.588268235 +0100 @@ -23,6 +23,8 @@ subdir := locale +include ../Makeconfig + headers = locale.h bits/locale.h langinfo.h xlocale.h # catnames is needed by OPTION_EGLIBC_LOCALE_CODE and by the 'intl' code. # If we put the latter in an option group, too, we can omit catnames --- End Message --- --- Begin Message --- Version: 2.21 On 2012-12-02 19:32, Alban Browaeys wrote: > Package: libc6 > Version: 2.16-0experimental1 > Severity: normal > > Dear Maintainer, > A local dpkg-buildpackage of the 2.16 package leads to this error: > make[3]: Entering directory `/home/prahal/checkout/glibc6/eglibc-2.16/locale' > /usr/bin/install -c -m 644 locale.h /usr/include/locale.h > /usr/bin/install: cannot remove '/usr/include/locale.h': Permission denied > make[3]: *** [/usr/include/locale.h] Error 1 > make[3]: Leaving directory `/home/prahal/checkout/glibc6/eglibc-2.16/locale' > make[2]: *** [locale/subdir_install] Error 2 > make[2]: Leaving directory `/home/prahal/checkout/glibc6/eglibc-2.16' > make[1]: *** [install] Erreur 2 > make[1] : on quitte le répertoire « > /home/prahal/checkout/glibc6/eglibc-2.16/build-tree/amd64-libc » > make: *** [/home/prahal/checkout/glibc6/eglibc-2.16/stamp-dir/install_libc] > Erreur 2 > dpkg-buildpackage: erreur: fakeroot debian/rules binary a produit une erreur > de sortie de type 2 > > It turns out the locale/Makefile is missing: > include ../Makeconfig This has been fixed upstream in version 2.20. I am therefore closing the bug. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net--- End Message ---
Bug#691371: marked as done (Broken COPY relocation with UNIQUE symbols (upstream #12510))
Your message dated Thu, 17 Dec 2015 19:47:47 +0100 with message-id <20151217184747.ga16...@aurel32.net> and subject line Re: Bug#691371: Broken COPY relocation with UNIQUE symbols (upstream #12510) has caused the Debian Bug report #691371, regarding Broken COPY relocation with UNIQUE symbols (upstream #12510) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 691371: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691371 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6 Version: 2.13-35 I just rediscovered http://sourceware.org/bugzilla/show_bug.cgi?id=12510 in my application. Fixed by http://sourceware.org/git/?p=glibc.git;a=commit;h=028478fa40d85a73b19638dbe3f83b1acebf370c Attached is the test-case I came up with before I found the commit that fixes it, and then the upstream bug. This is a regression in wheezy vs squeeze; gcc in squeeze didn't generate UNIQUE symbols (at least for this case), AND the old dynamic linker seems to not have this bug. The actual code part of that upstream patch applies cleanly to wheezy's libc and fixes the problem. ISTM that it'd be a good idea to backport, given that wheezy isn't going to upgrade to a new upstream release. test.h template class Foo { public: static const char foo[]; }; test1.cpp #include "test.h" // Creates a UNIQUE symbol (and thus hits dynamic linker bug), used to // create a WEAK symbol instead. template const char Foo::foo[] = "string"; template class Foo; const char * getone() { // Creates a R_X86_64_GLOB_DAT relocation return Foo::foo; } test2.cpp #include "test.h" #include #include int main() { // Reference creates a R_X86_64_COPY relocation if (strcmp(Foo::foo, "string")) { printf("'%s'\n", Foo::foo); return 1; } return 0; } test.sh g++ -fPIC -shared -o test.so test1.cpp g++ -o test test2.cpp ./test.so ./test --- End Message --- --- Begin Message --- Version: 2.17-1 On 2012-10-24 16:12, James Y Knight wrote: > Package: libc6 > Version: 2.13-35 > > I just rediscovered http://sourceware.org/bugzilla/show_bug.cgi?id=12510 in > my application. Fixed by > http://sourceware.org/git/?p=glibc.git;a=commit;h=028478fa40d85a73b19638dbe3f83b1acebf370c > > Attached is the test-case I came up with before I found the commit that fixes > it, and then the upstream bug. > > This is a regression in wheezy vs squeeze; gcc in squeeze didn't generate > UNIQUE symbols (at least for this case), AND the old dynamic linker seems to > not have this bug. > > The actual code part of that upstream patch applies cleanly to wheezy's libc > and fixes the problem. ISTM that it'd be a good idea to backport, given that > wheezy isn't going to upgrade to a new upstream release. > > test.h > template > class Foo { > public: > static const char foo[]; > }; > > test1.cpp > #include "test.h" > > // Creates a UNIQUE symbol (and thus hits dynamic linker bug), used to > // create a WEAK symbol instead. > template > const char Foo::foo[] = "string"; > template class Foo; > > const char * getone() { > // Creates a R_X86_64_GLOB_DAT relocation > return Foo::foo; > } > > test2.cpp > #include "test.h" > #include > #include > > int main() { > // Reference creates a R_X86_64_COPY relocation > if (strcmp(Foo::foo, "string")) { > printf("'%s'\n", Foo::foo); > return 1; > } > return 0; > } > > > test.sh > g++ -fPIC -shared -o test.so test1.cpp > g++ -o test test2.cpp ./test.so > ./test This bug has been fixed in upstream glibc 2.14. I am therefore closing the bug. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net--- End Message ---
Bug#742965: marked as done (libc0.1: openpty()/forkpty() fail on kfreebsd >=9.0)
Your message dated Thu, 17 Dec 2015 19:47:05 +0100 with message-id <20151217184705.ga9...@aurel32.net> and subject line Re: Bug#742965: libc0.1: openpty()/forkpty() fail on kfreebsd >=9.0 has caused the Debian Bug report #742965, regarding libc0.1: openpty()/forkpty() fail on kfreebsd >=9.0 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 742965: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742965 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc0.1 Version: 2.18-4 Severity: normal If a process has a handler for SIGCHLD, openpty() fails on kfreebsd with 9.x kernels. It worked ok on 8.x, and works on "real" (ie, no glibc) FreeBSD. A reduced test case attached; when commenting out the sigaction line, openpty() starts working again. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.2-1-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc0.1 depends on: ii libgcc1 1:4.8.2-16 libc0.1 recommends no packages. Versions of packages libc0.1 suggests: ii debconf [debconf-2.0] 1.5.52 pn glibc-doc ii locales2.18-4 -- debconf information: glibc/upgrade: true glibc/disable-screensaver: glibc/restart-services: glibc/restart-failed: libraries/restart-without-asking: false // Link with -lutil #include #include #include #include #include #include #include static void sigchild(int dummy) { while (waitpid(-1,0,WNOHANG)>0); } int main() { int master, slave; struct sigaction act; sigemptyset(&act.sa_mask); act.sa_flags=SA_RESTART; act.sa_handler=sigchild; sigaction(SIGCHLD,&act,0); if (openpty(&master, &slave, 0, 0, 0)) { printf("Failed: %s\n", strerror(errno)); return 1; } printf("Ok!\n"); return 0; } --- End Message --- --- Begin Message --- On 2014-04-04 09:35, Petr Salinger wrote: > >I wonder how to fix it. Merely documenting the restriction isn't really > >anoption, as no widespread system has it. Saving the signal handler, > >disabling it then restoring would work but introduces a slight race > >condition (a child process can exit while we're in grantpt()). > > In fact, it is documented: > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/grantpt.html > > The behavior of the grantpt() function is unspecified if the application > has installed a signal handler to catch SIGCHLD signals. Indeed this is a possible behaviour of this function. The same will happen on a GNU/Linux system if /dev/pts is mounted with the wrong permissions. I am therefore closing this bug. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net--- End Message ---
Processed: fixed 661760 in eglibc/2.17-1
Processing commands for cont...@bugs.debian.org: > fixed 661760 eglibc/2.17-1 Bug #661760 {Done: Aurelien Jarno } [locales] locales: The month 'February' must be 'Februar' in the locale de_AT, not 'Feber'. Marked as fixed in versions eglibc/2.17-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 661760: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661760 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#661760: marked as done (locales: The month 'February' must be 'Februar' in the locale de_AT, not 'Feber'.)
Your message dated Thu, 17 Dec 2015 19:36:16 +0100 with message-id <20151217183616.ga17...@aurel32.net> and subject line Re: Bug#661760: typo in patch for de_AT translation of February has caused the Debian Bug report #661760, regarding locales: The month 'February' must be 'Februar' in the locale de_AT, not 'Feber'. to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 661760: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661760 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: locales Version: 2.11.3-3 Severity: normal While the exotic form "Feber" does exist in parts of Austria and southern Germany, it is by no means the standard. Some old folks still know it exists, hardly anybody in Austria actually uses it. It must be "Februar". This causes me pain, because date-formatting is heavily used in our publishing company. PostgreSQL relies on the system locale and I have to special case the month every time. I fix /usr/share/i18n/locales/de_AT locally and run locale-gen. But it won't stick. The file is overwritten with every locale update - and I do want those updates. So, could this be fixed for good? Would be among the simplest bugfix ever: s/"";/"";/ Regards Erwin -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/6 CPU cores) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii libc6 [glibc-2.11-1] 2.11.3-3 Embedded GNU C Library: Shared lib locales recommends no packages. locales suggests no packages. -- debconf information: * locales/default_environment_locale: de_AT.UTF-8 * locales/locales_to_be_generated: de_AT.UTF-8 UTF-8, en_US.UTF-8 UTF-8 --- End Message --- --- Begin Message --- Version: eglibc/2.13-38+deb7u2 On 2013-01-18 15:45, Thomas Schwinge wrote: > Hi! > > Thanks for the report and patch! > > On Fri, 18 Jan 2013 14:58:39 +0100, Gerfried Fuchs wrote: > > --- a/localedata/locales/de_AT > > +++ b/localedata/locales/de_AT > > @@ -102,7 +102,7 @@ > > "";"";/ > > "";"" > > mon "";/ > > - "";/ > > + "";/ > > "";/ > > "";/ > > "";/ > > Please see upstream glibc commit b44d43a01620a29c0ee7b25fe994adb22fa511d5 > and BZ #13758; this has been fixed already: > > localedata/ > 2012-10-19 Florian Pritz > > [BZ #13758] > * locales/de_AT (LC_TIME): Change month name from "FebruAr" to > "Februar". > > > diff --git localedata/locales/de_AT localedata/locales/de_AT > index e566eed..c36913b 100644 > --- localedata/locales/de_AT > +++ localedata/locales/de_AT > @@ -100,7 +100,7 @@ abmon "";"";/ > "";"";/ > "";"" > mon "";/ > - "";/ > + "";/ > "";/ > "";/ > "";/ > This has been fixed in version 2.13-38+deb7u2. I am therefore closing the bug. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature --- End Message ---
Bug#572746: marked as done (libm: sinf/cosf performance is awful on amd64)
Your message dated Thu, 17 Dec 2015 19:35:14 +0100 with message-id <20151217183514.ga22...@aurel32.net> and subject line Re: Bug#572746: libm: sinf/cosf performance is awful on amd64 has caused the Debian Bug report #572746, regarding libm: sinf/cosf performance is awful on amd64 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 572746: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572746 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6 Version: 2.10.2-6 Severity: normal Hi, After many tests and research I've come to the conclusion that the float variants of sin/cos (and maybe others) are anormaly slow Debian amd64. The performance loss is really impressive (around 8 to 9 times slower). I've attached the prog used to make my experiments and used it in the following cases. + Lenny-amd64: sinf/cosf is really slow + Lenny-i386: float performance is ok (faster than the cos/sin using double) + Sid-amd64: sinf/cosf slow + Lenny-amd64 using lenny-i386 binary and 32bits libs: float performance is OK. + OpenSuse 64 bits (10.3 and 11.1): using the binary compiled on lenny-amd64, the tests run fine ! => The problem is not compiler related. There seems to be a problem with the way libm is compiled for the amd64 architecture on Debian. This is why the OpenSuse test was run: the problem is somewhere in the compile chain or debian specific patches. We're extensively using these for calculations and this is a real problem. Using cos/sin as a temporary workaround would do the trick but this is still slower than the sinf/cosf implementations that works so well on 32 bits computers... Thank you Jerome -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8) Shell: /bin/sh linked to /bin/bash Versions of packages libc6 depends on: ii libc-bin 2.10.2-6 Embedded GNU C Library: Binaries ii libgcc1 1:4.4.3-3 GCC support library libc6 recommends no packages. Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.28 Debian configuration management sy pn glibc-doc (no description available) ii locales 2.10.2-6 Embedded GNU C Library: National L -- debconf information excluded CC=gcc CFLAGS=-DNDEBUG -O3 -D_ISOC99_SOURCE -Wall -Wextra LDFLAGS=-lm all: test_trig clean: rm test_trig test_trig: test_trig.c #include #include #include int main(void) { const int nbElement_i = 1000; int i=0; float f1=0.0f, f2=0.0f, f3=0.0f; struct timeval tv1, tv2; printf("Testing %d sinf and cosf... ", nbElement_i); fflush(stdout); gettimeofday(&tv1, NULL); for(i=0; i--- End Message --- --- Begin Message --- Version: 2.17-1 On 2010-03-06 11:42, Jerome Vizcaino wrote: > Package: libc6 > Version: 2.10.2-6 > Severity: normal > > Hi, > > After many tests and research I've come to the conclusion that the float > variants > of > sin/cos (and maybe others) are anormaly slow Debian amd64. > The performance loss is really impressive (around 8 to 9 times slower). > I've attached the prog used to make my experiments and used it in the > following > cases. > > + Lenny-amd64: sinf/cosf is really slow > + Lenny-i386: float performance is ok (faster than the cos/sin using double) > + Sid-amd64: sinf/cosf slow > + Lenny-amd64 using lenny-i386 binary and 32bits libs: float performance is > OK. > > + OpenSuse 64 bits (10.3 and 11.1): using the binary compiled on lenny-amd64, > the tests run fine ! > => The problem is not compiler related. > > There seems to be a problem with the way libm is compiled for the amd64 > architecture on Debian. > This is why the OpenSuse test was run: the problem is somewhere in the > compile > chain or debian specific patches. > > We're extensively using these for calculations and this is a real problem. > Using > cos/sin as > a temporary workaround would do the trick but this is still slower than the > sinf/cosf > implementations that works so well on 32 bits computers... SSE2 based sinf/cosf optimized routines have been added in version 2.17-1, fixing the performance and precision issue. I am therefore closing this bug. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net--- End Message ---
Bug#661760: typo in patch for de_AT translation of February
Version: eglibc/2.13-38+deb7u2 On 2013-01-18 15:45, Thomas Schwinge wrote: > Hi! > > Thanks for the report and patch! > > On Fri, 18 Jan 2013 14:58:39 +0100, Gerfried Fuchs wrote: > > --- a/localedata/locales/de_AT > > +++ b/localedata/locales/de_AT > > @@ -102,7 +102,7 @@ > > "";"";/ > > "";"" > > mon "";/ > > - "";/ > > + "";/ > > "";/ > > "";/ > > "";/ > > Please see upstream glibc commit b44d43a01620a29c0ee7b25fe994adb22fa511d5 > and BZ #13758; this has been fixed already: > > localedata/ > 2012-10-19 Florian Pritz > > [BZ #13758] > * locales/de_AT (LC_TIME): Change month name from "FebruAr" to > "Februar". > > > diff --git localedata/locales/de_AT localedata/locales/de_AT > index e566eed..c36913b 100644 > --- localedata/locales/de_AT > +++ localedata/locales/de_AT > @@ -100,7 +100,7 @@ abmon "";"";/ > "";"";/ > "";"" > mon "";/ > - "";/ > + "";/ > "";/ > "";/ > "";/ > This has been fixed in version 2.13-38+deb7u2. I am therefore closing the bug. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#665408: marked as done (tzdata: San Luis and Cairo wrongly show UTC)
Your message dated Thu, 17 Dec 2015 19:35:42 +0100 with message-id <20151217183542.ga17...@aurel32.net> and subject line Re: Bug#665408: tzdata: San Luis and Cairo wrongly show UTC has caused the Debian Bug report #665408, regarding tzdata: San Luis and Cairo wrongly show UTC to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 665408: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665408 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: tzdata Version: 2011n-0lenny1 Severity: normal On a server with tzdata 2009l-0lenny1: dsatow@mercury11:~$ LANG= TZ=America/Argentina/San_Luis date Thu Mar 22 21:41:43 WART 2012 dsatow@mercury11:~$ LANG= TZ=Africa/Cairo date Fri Mar 23 03:41:55 EET 2012 dsatow@mercury11:~$ On a server with 2011n-0llenny1: martind@whitewater:~$ LANG= TZ=America/Argentina/San_Luis date Fri Mar 23 18:30:10 UTC 2012 martind@whitewater:~$ LANG= TZ=Africa/Cairo date Fri Mar 23 18:30:11 UTC 2012 martind@whitewater:~$ "WART" and "EET" change to "UTC". I believe this to be incorrect. This does not happen with the Squeeze libc and the same Lenny tzdata. I suspect that this was the fix: http://cygwin.com/ml/libc-alpha/2009-06/msg00102.html This demonstrates that the problem applies to many zones: for zone in `find /usr/share/zoneinfo/ -type f` do echo $zone; zdump -v $zone | tail -3 | head -1 done | grep UTC' isdst' Most such zones will only be affected tens of years in the future. The only zones, as of tzdata 2011k-0lenny1, that are currently affected are San Luis, Cairo and Egypt. All the affected zonefiles end with \x0A\x0A. But not all the zonefiles ending in such a way are affected. This casts doubt on my suspected fix. All such exceptions are under the right/ tree: martind@whitewater:~$ TZ=/usr/share/zoneinfo/right/America/Argentina/San_Luis date Fri Mar 23 17:30:06 WARST 2012 martind@whitewater:~$ hexdump -C /usr/share/zoneinfo/right/America/Argentina/San_Luis | tail -2 0640 00 00 00 0a 0a|.| 0645 martind@whitewater:~$ I suspect, though, that the reason that appears to work is another bug, fixed here: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=6355c99740c91ed5a7fa14e378f74950e09f5f48 I think that would prevent the empty tzspec from being read, except in the case where num_leaps is zero, explaining why that only afflicts the right/ tree. Returning to the original bug, this came to afflict San Luis in 2010j-0lenny1. 2010f-0lenny1 didn't exhibit the problem. It was a tzdata update, then, that led me to trip over the problem, which is part of the reason for my reporting a libc6 bug against tzdata. I don't expect, or even hope, for this to be fixed in Lenny. I would just like the report available to search engines so that the next person doesn't spend so long on it. I'd also like to raise awareness of the (small) risk of updating tzdata without updating libc6's tzfile code. -- System Information: Debian Release: 5.0.10 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tzdata depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy tzdata recommends no packages. tzdata suggests no packages. -- debconf information: tzdata/Zones/Australia: tzdata/Zones/Asia: tzdata/Zones/SystemV: tzdata/Zones/Pacific: tzdata/Zones/Atlantic: tzdata/Zones/US: tzdata/Zones/Etc: tzdata/Zones/Arctic: tzdata/Zones/Antarctica: * tzdata/Zones/Europe: Paris tzdata/Zones/Africa: * tzdata/Zones/America: Los_Angeles * tzdata/Areas: America tzdata/Zones/Indian: --- End Message --- --- Begin Message --- Version: 2.10.1-1 On 2012-10-19 16:59, Aurelien Jarno wrote: > reassign 665408 libc6 > fixed 665408 2.10.1-1 > thanks > > On Fri, Mar 23, 2012 at 02:40:36PM -0700, Martin Dorey wrote: > > Package: tzdata > > Version: 2011n-0lenny1 > > Severity: normal > > > > On a server with tzdata 2009l-0lenny1: > > > > dsatow@mercury11:~$ LANG= TZ=America/Argentina/San_Luis date > > Thu Mar 22 21:41:43 WART 2012 > > dsatow@mercury11:~$ LANG= TZ=Africa/Cairo date > > Fri Mar 23 03:41:55 EET 2012 > > dsatow@mercury11:~$ > > > > On a server with 2011n-0llenny1: > > > > martind@whitewater:~$ LANG= TZ=America/Argentina/San_Luis date > > Fri Mar 23 18:30:10 UTC 2012 > > martind@whitewater:~$ LANG= TZ=Africa/Cairo date > > Fri Mar 23 18:3
Bug#800682: marked as done (libc6: nscd reports bogus result for ipv6-only requests)
Your message dated Thu, 17 Dec 2015 19:35:24 +0100 with message-id <20151217183524.ga8...@aurel32.net> and subject line Re: Bug#800682: libc6: nscd reports bogus result for ipv6-only requests has caused the Debian Bug report #800682, regarding libc6: nscd reports bogus result for ipv6-only requests to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 800682: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800682 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6 Version: 2.19-20 Severity: normal Tags: upstream fixed-upstream patch Hello, without nscd: $ ping6 -n kamino PING kamino(2001:db8:210::20) 56 data bytes 64 bytes from 2001:db8:210::20: icmp_seq=1 ttl=64 time=0.303 ms with nscd: $ ping6 -n kamino PING kamino(a00:d214:2001:db8:210::) 56 data bytes (0x0a.0x00.0xd2.0x14 happens to be the IPv4 of kamino) This is due to a missing commit backport for Bug#798515. I have pushed the missing commit in the upstream 2.19 branch (8dc9751 cherry-picked as b0f0937). We can either upload a 2.19-23 to get it fixed, or just wait for 2.21 (which already has the fix) to get uploaded. Samuel -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.2 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- Samuel ... et Ctrl alt F2 pour aller sous console mais c koi pour passer d'un bureau a un autre ! au fait c koi le raccourci pour passer d'un bureau a un autre 'question stupide" ça dépend du window manager et de ta conf ce qui fonctionne toujours c'est CTRL-ALT-BCKSP -:- SignOff rv_: #linuxfr (Read error: EOF from client) -:- rv_ [~rv@217.11.166.169] has joined #linuxfr Firebird: MEURT... commit 8dc9751764eb1bedf06d19695524b31a16773413 Author: Andreas Schwab Date: Wed May 7 11:47:20 2014 +0200 Fix parsing of getai result from nscd for IPv6-only request diff --git a/ChangeLog b/ChangeLog index 6c50016..cb09dd7 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,7 +1,13 @@ +2014-05-07 Andreas Schwab + + * sysdeps/posix/getaddrinfo.c (gaih_inet): Advance address pointer + when skipping over non-matching result from nscd. + 2014-05-07 Ondřej Bílka [BZ #16876] * nptl/sockperf.c (client): Check socket return value. + [BZ #16877] * nscd/selinux.c (nscd_request_avc_has_perm): Check if there is nscd security class. diff --git a/sysdeps/posix/getaddrinfo.c b/sysdeps/posix/getaddrinfo.c index 3385bed..6258330 100644 --- a/sysdeps/posix/getaddrinfo.c +++ b/sysdeps/posix/getaddrinfo.c @@ -710,16 +710,20 @@ gaih_inet (const char *name, const struct gaih_service *service, struct gaih_addrtuple *addrfree = addrmem; for (int i = 0; i < air->naddrs; ++i) { + socklen_t size = (air->family[i] == AF_INET + ? INADDRSZ : IN6ADDRSZ); + if (!((air->family[i] == AF_INET && req->ai_family == AF_INET6 && (req->ai_flags & AI_V4MAPPED) != 0) || req->ai_family == AF_UNSPEC || air->family[i] == req->ai_family)) - /* Skip over non-matching result. */ - continue; + { + /* Skip over non-matching result. */ + addrs += size; + continue; + } - socklen_t size = (air->family[i] == AF_INET - ? INADDRSZ : IN6ADDRSZ); if (*pat == NULL) { *pat = addrfree++; --- End Message --- --- Begin Message --- Version: 2.21-1 On 2015-10-02 13:57, Samuel Thibault wrote: > Package: libc6 > Version: 2.19-20 > Severity: normal > Tags: upstream fixed-upstream patch > > Hello, > > without nscd: > $ ping6 -n kamino > PING kamino(2001:db8:210::20) 56 data bytes > 64 bytes from 2001:db8:210::20: icmp_seq=1 ttl=64 time=0.303 ms > > with nscd: > $ ping6 -n kamino > PING kamino(a00:d214:2001:db8:210::) 56 data bytes > > (0x0a.0x00.0xd2.0x14 happens to be the IP
Bug#800523: nscd netgroup cache occasionally not updated, nscd -i netgroup hangs
On 2015-09-30 12:29, Mike Gabriel wrote: > Package: nscd > Severity: important > Version: 2.19-18+deb8u1 > Tags: patch > Usertags: debian-edu > User: debian-...@lists.debian.org > X-Debbugs-Cc: debian-...@lists.debian.org > > Dear maintainers, > > the Debian Edu main server in jessie heavily relies on working netgroups > code in glibc / nscd for allowing NFS access from hosts on the network. > > The setup is: > > /etc/nsswitch.conf: > > """ > netgroup:files ldap > """ > > The LDAP nss provider is libnss-ldapd via nslcd. NIS netgroups are only > configured in LDAP, no local /etc/netgroup file is present. NIS netgroup > caching in nscd.conf is enabled. > > In some cases (unclear what triggers it) the following is observed: > > o add a new host to the NIS netgroup "workstation-hosts" > o wait for a while (i.e., we even tried days...) > o "getent netgroup workstation-hosts" does not list the new host as > netgroup member > o trying > > $ innetgr -h workstation-hosts || echo FALSE > > echoes "FALSE" on the terminal. > o sometimes there even is a difference between what getent netgroup > gives > as a result and what innetgr returns as a result (a host tripled is > listed in > getent netgroup , but when querying for that host via innetgr). > o Attempting cache clean-up (nscd -i netgroup) fails, the command hangs and > does not return to a command prompt > > The behaviour occurs very often on Debian Edu jessie main server > installations (and also on a vanilla Debian jessie server using a similar > NIS netgroup / NFS setup). It does not occur always. Note, that I always > have host netgroups that are full with host triplets (long strings!!! > several lines on a normal 80x25 terminal). > > From looking at debdiffs between glibc in unstable and jessie > (2.19-18+deb8u1), the issue is probably also present in Debian unstable, but > may have been fixed in glibc 2.21 (currently in experimental). Given I don't have a test setup to reproduce the issue, and now that 2.21 is in testing, it would be nice if you can give a try with this version to see if it improves things. That will at least tell us if we have to look at patches to backports or at writing patches to fix the issues. > The debdiff between glibc in wheezy (2.13-38+deb7u8) and jessie > (2.19-18+deb8u1) alludes that the changes around the netgroup caching code > (there have been quite some nscd caching changes between those two version) > may have caused this issue between glibc 2.13 and 2.19. > > The above issue is definitely not present in glibc from Debian squeeze (we > have many servers running that versions) and probably neither present in > Debian wheezy (only one test server deployed), but really really bites us > (the Debian Edu team) on Debian Edu jessie. > > The workaround at the moment is: disable nscd netgroup caching in nscd.conf. > This is by far suboptimal. > > Upstream observed issues with (LDAP and) netgroup caching, as well, recently: > > https://sourceware.org/bugzilla/show_bug.cgi?id=16878 > Patch: > https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=c3ec475c5dd16499aa040908e11d382c3ded9692;hp=aa2f176d6f75b86b91e544c2e494066ac8f88cbd This has already been backported to jessie. > https://sourceware.org/bugzilla/show_bug.cgi?id=16760 > https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=dd3022d75e6fb8957843d6d84257a5d8457822d5 This one is actually from BZ 16759 > https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=ea7d8b95e2fcb81f68b04ed7787a3dbda023991a It looks indeed a good idea to backport them. > https://sourceware.o rg/bugzilla/show_bug.cgi?id=16695 > https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=c44496df2f090a56d3bf75df930592dac6bba46f This has already been backported to jessie. > https://sourceware.org/bugzilla/show_bug.cgi?id=16758 > https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=fbd6b5a4052316f7eb03c4617eebfaafc59dcc06 > > Especially BZ #16878 looks like being a good candidate to fix this. My > recommendation is considering backporting all of the above patches as by > reading those bug reports, glibc 2.19 seems quite buggy regarding netgroup > caching in nscd. I will try to backport them for the next point release. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: Fixing the armhf linker path
On Wed, Dec 16, 2015 at 11:30:53PM +0100, Aurelien Jarno wrote: >At the beginning of the armhf port the hard-float dynamic linker has >been chosen to be '/lib/arm-linux-gnueabihf/ld-linux.so.3'. However it >has been standardized later as '/lib/ld-linux-armhf.so.3' [1]. We have >changed it in Debian, and added a patch to the glibc [2] to temporarily >support both paths, until all the packages have been rebuilt with the >new path. > >However we failed to do it for Wheezy. We also failed to do it for >Jessie. So let's do it for Stretch, so that we can drop the glibc >patches in Buster, and ensure binary compatibility with other >distributions. > >For that we first need to binNMU the packages which have not been >rebuilt since the dynamic linker change in unstable (see the list at >the end of the mail). Then we can have a look at getting all of them >migrated to testing. > >Any comments or objections? ACK, this makes sense. I spoke with Adam a while back about doing this. I promised I'd scan the archive for any packages still relying on the old linker path, but I've not got to it yet - sorry. :-/ -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Bug#808181: Re[2]: Bug#808181: libc6: Upgrade can make the linker unusable
Hi, > We are working to migrate binutils version 2.25.90.20151209-1 into > testing asap. If everything goes well it should be the case after the > 13:52 UTC dinstall run, so a few hours after that on the mirrors. > > In the meantime fetching and installing this version from sid, should > solve the issue. Thanks, that version solved the issue indeed. Compilation goes fine now.
Processed: Re: Bug#808181: libc6: Upgrade can make the linker unusable
Processing commands for cont...@bugs.debian.org: > reassign 808181 libc6-dev Bug #808181 [libc6] libc6: Upgrade can make the linker unusable Bug reassigned from package 'libc6' to 'libc6-dev'. Ignoring request to alter found versions of bug #808181 to the same values previously set Ignoring request to alter fixed versions of bug #808181 to the same values previously set > reassign 808205 libc6-dev Bug #808205 [libc6] libc6: Unrecognized relocation when compiling Bug reassigned from package 'libc6' to 'libc6-dev'. No longer marked as found in versions glibc/2.21-4. Ignoring request to alter fixed versions of bug #808205 to the same values previously set > forcemerge 808181 808205 Bug #808181 [libc6-dev] libc6: Upgrade can make the linker unusable Bug #808205 [libc6-dev] libc6: Unrecognized relocation when compiling Added tag(s) stretch. Merged 808181 808205 > forcemerge 808181 808206 Bug #808181 [libc6-dev] libc6: Upgrade can make the linker unusable Bug #808205 [libc6-dev] libc6: Unrecognized relocation when compiling Bug #808205 [libc6-dev] libc6: Unrecognized relocation when compiling Marked as found in versions glibc/2.21-4. Marked as found in versions glibc/2.21-4. Bug #808206 [libc6-dev] unsupported reloc 42 against global symbol __gmon_start__ Severity set to 'important' from 'normal' Added tag(s) stretch. Merged 808181 808205 808206 > severity 808181 serious Bug #808181 [libc6-dev] libc6: Upgrade can make the linker unusable Bug #808205 [libc6-dev] libc6: Unrecognized relocation when compiling Bug #808206 [libc6-dev] unsupported reloc 42 against global symbol __gmon_start__ Severity set to 'serious' from 'important' Severity set to 'serious' from 'important' Severity set to 'serious' from 'important' > thanks Stopping processing here. Please contact me if you need assistance. -- 808181: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808181 808205: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808205 808206: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808206 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#808181: libc6: Upgrade can make the linker unusable
reassign 808181 libc6-dev reassign 808205 libc6-dev forcemerge 808181 808205 forcemerge 808181 808206 severity 808181 serious thanks On 2015-12-16 23:36, Aurelien Jarno wrote: > On 2015-12-16 13:15, Dima Kogan wrote: > > Package: libc6 > > Severity: normal > > > > Hi. I had > > > > libc6= 2.19-22 > > binutils = 2.25-4 > > > > and all was well. Then I upgraded to libc6 = 2.21-4 (currently latest in > > sid). As a result, even the most basic build-time linking would fail. > > For instance, with a trivial hello-world program: > > > > $ gcc-5 -o tst tst.c > > > > /usr/bin/ld: > > /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o: > > unrecognized relocation (0x2a) in section `.init' > > /usr/bin/ld: final link failed: Bad value > > collect2: error: ld returned 1 exit status > > > > This would happen with gcc-5 and with gcc-4.9. Downgrading libc6 would > > fix it. After some fiddling I realized that upgrading to binutils = > > 2.25.90.20151209-1 (currently latest in sid) fixes it. I.e. with the > > latest libc6 and the latest binutils packages things work. > > The problem is not introduced by the glibc, but just by the fact that > it has been built with a recent binutils version which adds new > relocation types on i386 and amd64. This means that ALL static libraries > are affected by this problem. > > > Can the broken combination be prevented with some Conflicts: tags? > > Currently this is a trap for the unwary. > > I therefore don't think we need to fix that at the glibc level. Either > we just ignore the problem saying we don't support partial upgrades or > we try to find a global way to fix the dependencies for all libraries. We are working to migrate binutils version 2.25.90.20151209-1 into testing asap. If everything goes well it should be the case after the 13:52 UTC dinstall run, so a few hours after that on the mirrors. In the meantime fetching and installing this version from sid, should solve the issue. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#808206: unsupported reloc 42 against global symbol __gmon_start__
Package: libc6-dev Version: 2.21-4 $ gcc -x c -
Bug#808181: libc6: Upgrade can make the linker unusable
Control: severity -1 important Control: tags -1 stretch Hi, Just stumbled upon this today in Testing (Stretch) - after today's libc6 upgrade. This issue breaks compilation of ANY autotools-based project as ld fails early in the configure phase: configure:3441: checking whether the C compiler works configure:3463: gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro conftest.c >&5 /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o: unrecognized relocation (0x2a) in section `.init' /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status The system has been updated with the usual dist-upgrade, so I don't understand the mentioning of some partial upgrades above (and completely don't understand the part about "ignore the problem").
Processed: Re: Bug#808181: libc6: Upgrade can make the linker unusable
Processing control commands: > severity -1 important Bug #808181 [libc6] libc6: Upgrade can make the linker unusable Severity set to 'important' from 'normal' > tags -1 stretch Bug #808181 [libc6] libc6: Upgrade can make the linker unusable Added tag(s) stretch. -- 808181: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808181 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#808205: libc6: Unrecognized relocation when compiling
Package: libc6 Version: 2.21-4 Severity: important Dear Maintainer, When attempting to compile a simple C program, the link stage fails with an unrecognized relocation error. This problem seems to have appeared in the latest version, 2.21-4 (and is also present in 2.22-0experimental which I tested before submitting); it was not present in 2.19-22 which I was using prior to tonight. When using 2.19-22 (pinned to that version after installing the package from a CD), it works normally. When upgraded, it fails as per below. The problem manifested in a much more complicated build process, but I can duplicate it with a program as simple as this: #include int main() { fprintf(stdout, "Hello, world.\n"); return(0); } When compiling, the following error happens: $ gcc hello.c -o hello /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o: unrecognized relocation (0x2a) in section `.init' /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status The expected behavior is for the program to compile normally without error. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libc6 depends on: ii libgcc1 1:5.2.1-23 libc6 recommends no packages. Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.58 pn glibc-doc ii libc-l10n 2.22-0experimental1 ii locales2.21-4 -- debconf information: glibc/disable-screensaver: glibc/restart-services: glibc/kernel-not-supported: * libraries/restart-without-asking: true glibc/restart-failed: glibc/upgrade: true glibc/kernel-too-old:
Bug#808181: libc6: Upgrade can make the linker unusable
Dear developers, I've just got bitten by this bug. About 3 millimeters from my carotid artery... This bugs effectively renders my system unusable for compilation purposes : even extremely mundane uses, such as upgradng some R packages, is now impossible. Suggestions : 1) The gravity of this bug should be elevated : it renders the system unusable at least for some mundane uses. 2) The upgrade to glibc should be conditioned to the upgrade of binutils 3) A workaround should be posted on this bug report as soon as possible (upgrade to unstable's binutils ?), and possibly publicized by larger means (finding this bug is not obvious for pedestrian users like me...). Sincerely yours, -- Emmanuel Charpentier
Bug#808181: libc6: Upgrade can make the linker unusable
I am not sure to understand correctly... I currently have the same behavior with Stretch without sid/experimental repository, and I see binutils is not ready to migrate from testing, so no partial updates here I think. I do not understand how libc6-dev came built with an unavailable binutils version on Stretch. Christophe