Bug#741031: I can confirm this bug, too

2014-05-06 Thread Robert Waldner

On Mon, 05 May 2014 10:13:51 +0200, Robert Waldner writes:
Trying to upgrade to current Jessie, eg. from 2.17-97 to 2.18-5, got 
 libc6-amd64:i386 into a state where it seems impossible to continue.
 Removing libc6-amd64:i386 fails because the package is in a bad 
 state, reinstalling doesn't work, either, nor das apt-get -f install:

At first failure, I tried with the steps outlined in #736097, and (like 
 Francesco) hosed my system - luckily I had sash installed and could 
 revocer via that.

Now it seems I'm stuck in a loop:

FWIW, after some experimentation in a chrooted copy of the system I was 
 able to revover, here's a snippet of my shell history:

  588  LD_LIBRARY_PATH=/lib/x86_64-linux-gnu/ apt-get -f install

Didn't help. every new process would just segfault, until (ldconfig 
 had been symlinked to /bin/true before):
  589  /sbin/ldconfig.real 

Seems the apt-get -f install with LD_LIBRARY_PATH set got me far enough 
 so that now it was possible to continue w/o errors:
  590  apt-get -f install
  591  apt-get -s remove libc6-amd64
  592  apt-get -s --purge remove libc6-amd64
  593  apt-get --purge remove libc6-amd64

Now I'm in a state without broken/half-installed libc6* packages, finally
 could get rid of libc6-amd64, and can continue with upgrading:

:) waldner@fsck-~ $ COLUMNS=72 dpkg -l | grep libc6 | egrep ^i
ii  libc6:amd642.18-5   amd64Embedded GNU C Library: Shared li
ii  libc6:i386 2.18-5   i386 Embedded GNU C Library: Shared li
ii  libc6-dbg:amd6 2.18-5   amd64Embedded GNU C Library: detached 
ii  libc6-dev:amd6 2.18-5   amd64Embedded GNU C Library: Developme
ii  libc6-dev:i386 2.18-5   i386 Embedded GNU C Library: Developme
ii  libc6-dev-i386 2.18-5   amd64Embedded GNU C Library: 32-bit de
ii  libc6-dev-x32  2.18-5   amd64Embedded GNU C Library: X32 ABI D
ii  libc6-i386 2.18-5   amd64Embedded GNU C Library: 32-bit sh
ii  libc6-x32  2.18-5   amd64Embedded GNU C Library: X32 ABI S

Kind regards,
robert
-- 
-- Too much is just enough.
-- Mark Twain (on whiskey)




signature.asc
Description: Digital Signature


Bug#741031: I can confirm this bug, too

2014-05-06 Thread Aurelien Jarno
On Mon, May 05, 2014 at 10:13:51AM +0200, Robert Waldner wrote:
 
 Trying to upgrade to current Jessie, eg. from 2.17-97 to 2.18-5, got 
  libc6-amd64:i386 into a state where it seems impossible to continue.
  Removing libc6-amd64:i386 fails because the package is in a bad 
  state, reinstalling doesn't work, either, nor das apt-get -f install:
 
 At first failure, I tried with the steps outlined in #736097, and (like 
  Francesco) hosed my system - luckily I had sash installed and could 
  revocer via that.
 
 Now it seems I'm stuck in a loop:
 
  # apt-get -f install
 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 Correcting dependencies... Done
 The following extra packages will be installed:
   libc-bin libc6 libc6-amd64:i386
 Suggested packages:
   glibc-doc
 The following packages will be upgraded:
   libc-bin libc6 libc6-amd64:i386
 3 upgraded, 0 newly installed, 0 to remove and 1235 not upgraded.
 12 not fully installed or removed.
 Need to get 0 B/8,518 kB of archives.
 After this operation, 115 kB disk space will be freed.
 Do you want to continue? [Y/n] 
 Preconfiguring packages ...
 (Reading database ... 294301 files and directories currently installed.)
 Preparing to unpack .../libc6-amd64_2.18-5_i386.deb ...
 Unpacking libc6-amd64 (2.18-5) over (2.17-97) ...
 Replaced by files in installed package libc6:amd64 (2.17-97) ...
 dpkg: warning: subprocess old post-removal script was killed by signal 
 (Segmentation fault)
 dpkg: trying script from the new package instead ...
 dpkg: error processing archive 
 /var/cache/apt/archives/libc6-amd64_2.18-5_i386.deb (--unpack):
  subprocess new post-removal script was killed by signal (Segmentation fault)
 dpkg: error while cleaning up:
  subprocess installed pre-installation script was killed by signal 
 (Segmentation fault)
 Preparing to unpack .../libc6_2.18-5_amd64.deb ...
 Checking for services that may need to be restarted...
 Checking init scripts...
 Warning: found a potentially broken dynamic loader symlink,
 disabling ldconfig to avoid a possible system breakage. It
 will be reenabled when a new version of libc-bin is unpacked.
 Unpacking libc6:amd64 (2.18-5) over (2.17-97) ...
 dpkg: warning: subprocess old post-removal script was killed by signal 
 (Segmentation fault)
 dpkg: trying script from the new package instead ...
 dpkg: error processing archive /var/cache/apt/archives/libc6_2.18-5_amd64.deb 
 (--unpack):
  subprocess new post-removal script was killed by signal (Segmentation fault)
 dpkg: error while cleaning up:
  subprocess installed pre-installation script was killed by signal 
 (Segmentation fault)
 Errors were encountered while processing:
  /var/cache/apt/archives/libc6-amd64_2.18-5_i386.deb
  /var/cache/apt/archives/libc6_2.18-5_amd64.deb
 E: Sub-process /usr/bin/dpkg returned an error code (1)
 :( root@fsck-/usr/local/src/games # apt-get remove libc6-amd64:i386
 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 You might want to run 'apt-get -f install' to correct these:
 The following packages have unmet dependencies:
  libc-bin : Depends: libc6 ( 2.18) but 2.18-5 is to be installed
 E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify 
 a solution).
 :( root@fsck-/usr/local/src/games # apt-get --reinstall install libc6-amd64- 
 libc6 libc-bin
 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 Suggested packages:
   glibc-doc
 The following packages will be REMOVED:
   libc6-amd64:i386
 The following packages will be upgraded:
   libc-bin libc6
 2 upgraded, 0 newly installed, 1 to remove and 1235 not upgraded.
 12 not fully installed or removed.
 Need to get 0 B/5,927 kB of archives.
 After this operation, 11.0 MB disk space will be freed.
 Do you want to continue? [Y/n] 
 Preconfiguring packages ...
 dpkg: error processing package libc6-amd64 (--remove):
  package is in a very bad inconsistent state; you should
  reinstall it before attempting a removal
 E: Sub-process /usr/bin/dpkg returned an error code (1)
 :( root@fsck-/usr/local/src/games # dpkg -r libc6-amd64 
 dpkg: error processing package libc6-amd64 (--remove):
  package is in a very bad inconsistent state; you should
  reinstall it before attempting a removal
 Errors were encountered while processing:
  libc6-amd64
 :( root@fsck-/usr/local/src/games # apt-get --reinstall install 
 libc6-amd64:i386
 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 You might want to run 'apt-get -f install' to correct these:
 The following packages have unmet dependencies:
  libc-bin : Depends: libc6 ( 2.18) but 2.18-5 is to be installed
 E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify 
 a solution).
 :( root@fsck-/usr/local/src/games # apt-get -f install
 Reading package lists... Done
 Building dependency tree   
 

Bug#741031: I can confirm this bug, too

2014-05-06 Thread Robert Waldner

On Tue, 06 May 2014 08:44:02 +0200, Aurelien Jarno writes:
On Mon, May 05, 2014 at 10:13:51AM +0200, Robert Waldner wrote:
 
 Trying to upgrade to current Jessie, eg. from 2.17-97 to 2.18-5, got 
  libc6-amd64:i386 into a state where it seems impossible to continue.
  Removing libc6-amd64:i386 fails because the package is in a bad 
  state, reinstalling doesn't work, either, nor das apt-get -f install:
 
 At first failure, I tried with the steps outlined in #736097, and (like 
  Francesco) hosed my system - luckily I had sash installed and could 
  revocer via that.
 
 Now it seems I'm stuck in a loop:

Before trying to provide any hint, but also to be able to understand and
fix the problem, we need to have a clear status of your system. Could
you please run the following commands and send us the output:

- dpkg -l libc*
- ls -l /lib /lib32 /lib64 /lib/i386-linux-gnu/ /lib/x86_64-linux-gnu/

Hi Aurelien,

sorry, your mail overlapped with me managing to get back to a working 
 system.

I've got most of the state of the libc6* (not libc*) packages still in 
 the scroll buffer, but not all of it (this is literally the top of the 
 scroll buffer):

iU  libc6-amd64   2.18-5
i386 Embedded GNU C Library: 64bit Shared libraries for AMD64
iU  libc6-dbg:amd64   2.18-5
amd64Embedded GNU C Library: detached debugging symbols
iU  libc6-dev:amd64   2.18-5
amd64Embedded GNU C Library: Development Libraries and Header Files
iU  libc6-dev:i3862.18-5
i386 Embedded GNU C Library: Development Libraries and Header Files
iU  libc6-dev-i3862.18-5
amd64Embedded GNU C Library: 32-bit development libraries for AMD64
iU  libc6-dev-x32 2.18-5
amd64Embedded GNU C Library: X32 ABI Development Libraries for AMD64
iU  libc6-i3862.18-5
amd64Embedded GNU C Library: 32-bit shared libraries for AMD64
rc  libc6-i686:i386   2.13-38   
i386 Embedded GNU C Library: Shared libraries [i686 optimized]
iU  libc6-x32 2.18-5
amd64Embedded GNU C Library: X32 ABI Shared libraries for AMD64
:) root@fsck-/usr/local/src/games # ls -la /lib/x86_64-linux-gnu/libdl-2.1*
-rw-r--r-- 1 root root 14664 Nov 29 18:00 /lib/x86_64-linux-gnu/libdl-2.17.so

I could get the rest of the output, but it'd be from the working 
 system, so I guess there wouldn't much of a point.

Thanks for taking the time and trying to help me out.

Kind regards,
robert
-- 
-- You're lost in the maze of /usr/ucb and /usr/xpg/bin. An evil
--  tset attacks you. - az about Solaris




signature.asc
Description: Digital Signature


Bug#702617: regex /./ fails to match certiain characters

2014-05-06 Thread Aurelien Jarno
On Mon, Mar 11, 2013 at 06:13:07PM +0100, Joachim Breitner wrote:
 Control: reassign -1 libc6
 Control: found libc6/2.13-38
 Control: affects haskell-regex-compat
 
 Hi,
 
 Am Montag, den 11.03.2013, 11:53 -0400 schrieb Joey Hess:
  Joachim Breitner wrote:
   I can reproduce it from within ghc’s address space using gdb:
   
   (gdb) call malloc(32)
   $7 = 64943120
   (gdb) call regcomp(64943120, ., 0)
   $8 = 0
   (gdb) call regexec(64943120,\242,0,0,0)
   $9 = 1
   (gdb) call regexec(64943120,only_ascii,0,0,0)
   $10 = 0
   
   And even from gdb while debugging “sleep”. So the behaviour is already
   there in regexec, but for some reason it is not triggered from C code,
   but only via some variants of FFI (GHC’s or gdb’s).
   
   I’ll leave it at that, as this is not really related to GHC or Haskell
   any more.
  
  That's some deep dive!
  
  Sounds like a reassign to glibc is in order?
 
 if you think so...
 
 @glibc maintainers, here is the short story:
 
 This code prints, as expected 0 (for regex matches):
 
 #include sys/types.h
 #include regex.h
 #include stdio.h
 
 main () {
   regex_t r;
   regcomp(r, ., 0);
   char *s = \242;
   int i = regexec(r, s, 0, NULL, 0);
   printf(%d\n, i);
 }
 
 But in some circumstances, this does not work as expected. One such
 circumstance is Haskell code doing this via the FFI, but also from gdb:

What you see is actually very likely locale related. The \242
character is not valid in unicode locale. If you run your code using a
unicode locale, as regcomp() and regexec() interpret the regex and the
string as unicode, the \242 character is ignored.

The behavior you describe can be reproduced in you C example by adding 
a call to setlocale(LC_ALL, C.UTF-8) at the beginning of your code.

When you test with FFI or from GDB, it is very likely you have a
unicode locale defined.

 (gdb) call malloc(32)
 $1 = 6332464
 (gdb) call memset(6332464, 0, 32)
 $3 = 6332464
 (gdb) call regcomp(6332464, ., 0)
 $4 = 0
 (gdb) call regexec(6332464, \242,0,0,0)
 $5 = 1

\242 is ignored as it is a unicode character.

 It fails if there are no ascii characters around:
 
 (gdb) call regexec(6332464, \242x,0,0,0)
 $6 = 0

Here only the x is matched.

 (gdb) call regexec(6332464, \242\242,0,0,0)
 $7 = 1

No valid unicode character, nothing is matched.

 (gdb) call regexec(6332464, only_ascii,0,0,0)
 $8 = 0

Here the o is matched.


I am therefore tempted to reassign the bug back to
libghc-regex-compat-dev. Do you agree?

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140506072524.ga31...@volta.rr44.fr



Processed (with 1 errors): Re: Bug#702617: regex /./ fails to match certiain characters

2014-05-06 Thread Debian Bug Tracking System
Processing control commands:

 reassign -1 haskell-regex-posix
Bug #702617 [libc6] . fails to match certian characters
Bug reassigned from package 'libc6' to 'haskell-regex-posix'.
Ignoring request to alter found versions of bug #702617 to the same values 
previously set
Ignoring request to alter fixed versions of bug #702617 to the same values 
previously set
 forwarded -1 textregexl...@personal.mightyreason.com
Bug #702617 [haskell-regex-posix] . fails to match certian characters
Set Bug forwarded-to-address to 'textregexl...@personal.mightyreason.com'.
 tag + upstream
Unknown command or malformed arguments to command.


-- 
702617: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702617
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.b702617.139936389430785.transcr...@bugs.debian.org



Bug#702617: regex /./ fails to match certiain characters

2014-05-06 Thread Joachim Breitner
Control: reassign -1 haskell-regex-posix
Control: forwarded -1 textregexl...@personal.mightyreason.com
Control: tag + upstream

Hi,

Am Dienstag, den 06.05.2014, 09:25 +0200 schrieb Aurelien Jarno:
 What you see is actually very likely locale related. The \242
 character is not valid in unicode locale. If you run your code using a
 unicode locale, as regcomp() and regexec() interpret the regex and the
 string as unicode, the \242 character is ignored.
 
 The behavior you describe can be reproduced in you C example by adding 
 a call to setlocale(LC_ALL, C.UTF-8) at the beginning of your code.

Thanks! Indeed observable on the Haskell level:

Prelude System.Locale.SetLocale Text.Regex setLocale LC_ALL (Just C.UTF-8)
Just C.UTF-8
Prelude System.Locale.SetLocale Text.Regex let s = ò
Prelude System.Locale.SetLocale Text.Regex matchRegex (mkRegex $ ^.*$) s
Nothing
Prelude System.Locale.SetLocale Text.Regex setLocale LC_ALL (Just C)
Just C
Prelude System.Locale.SetLocale Text.Regex matchRegex (mkRegex $ ^.*$) s
Just []

The problems seems to be that Text.Regex.Posix uses newCAString and not
newCString. The latter converts the Haskell unicode string to the binary
representation, and if I do it by hand, I get:

Prelude Foreign.C.String Text.Regex.Posix.Wrap cs - newCString \242
Prelude Foreign.C.String Text.Regex.Posix.Wrap cp - newCString .
Prelude Foreign.C.String Text.Regex.Posix.Wrap Right r2 - wrapCompile 0 0 cp
Prelude Foreign.C.String Text.Regex.Posix.Wrap wrapTest r2 cs
Right True

(Compare that with what I did in https://bugs.debian.org/702617#22)

 I am therefore tempted to reassign the bug back to
 libghc-regex-compat-dev. Do you agree?

Yes, just done that.

Dear Christopher: Is there a good reason why regex-posix uses
newCAString, and not newCString, when converting Haskell Stings to C
strings?

Thanks,
Joachim


Greetings,
Joachim

-- 
Joachim nomeata Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



signature.asc
Description: This is a digitally signed message part


r6049 - in glibc-package/trunk/debian: . patches patches/any

2014-05-06 Thread Aurelien Jarno
Author: aurel32
Date: 2014-05-06 14:53:47 + (Tue, 06 May 2014)
New Revision: 6049

Added:
   glibc-package/trunk/debian/patches/any/submitted-nl_langinfo-static.diff
Modified:
   glibc-package/trunk/debian/changelog
   glibc-package/trunk/debian/patches/series
Log:
patches/any/submitted-nl_langinfo-static.diff: new patch to fix
nl_langinfo() used in static binaries.  Closes: #747103.

Modified: glibc-package/trunk/debian/changelog
===
--- glibc-package/trunk/debian/changelog2014-05-05 16:29:31 UTC (rev 
6048)
+++ glibc-package/trunk/debian/changelog2014-05-06 14:53:47 UTC (rev 
6049)
@@ -28,6 +28,8 @@
 #733237.
   * patches/any/cvs-socketcall-syscall.diff: new patch from upstream to fix
 socketcall multiplex syscall features detection.  Closes: #730744.
+  * patches/any/submitted-nl_langinfo-static.diff: new patch to fix
+nl_langinfo() used in static binaries.  Closes: #747103.
 
  -- Adam Conrad adcon...@0c3.net  Sun, 27 Apr 2014 23:15:13 -0600
 

Added: glibc-package/trunk/debian/patches/any/submitted-nl_langinfo-static.diff
===
--- glibc-package/trunk/debian/patches/any/submitted-nl_langinfo-static.diff
(rev 0)
+++ glibc-package/trunk/debian/patches/any/submitted-nl_langinfo-static.diff
2014-05-06 14:53:47 UTC (rev 6049)
@@ -0,0 +1,89 @@
+ 2014-05-06  Aurelien Jarno  aurel...@aurel32.net
+ 
+   * locale/nl_langinfo_l.c: Make direct reference to every
+   _nl_current_CATEGORY symbol.
+   * localedata/Makefile (test-srcs): Add tst-langinfo-static.
+   (tests-static): Add tst-langinfo-static.
+   (tests-special): Add tst-langinfo-static.out.
+   ($(objpfx)tst-langinfo.out): Redirect output.
+   ($(objpfx)tst-langinfo-static.out): New.
+   * localedata/tst-langinfo.sh: Send output to stdout.
+   * localedata/tst-langinfo-static.c: New file.
+
+diff --git a/locale/nl_langinfo_l.c b/locale/nl_langinfo_l.c
+--- a/locale/nl_langinfo_l.c
 b/locale/nl_langinfo_l.c
+@@ -43,7 +43,21 @@ __nl_langinfo_l (item, l)
+   if (index == _NL_ITEM_INDEX (_NL_LOCALE_NAME (category)))
+ return (char *) l-__names[category];
+ 
++#if defined NL_CURRENT_INDIRECT
++  /* Make direct reference to every _nl_current_CATEGORY symbol,
++ since we know only at runtime which categories are used.  */
++  switch (category)
++{
++# define DEFINE_CATEGORY(category, category_name, items, a) \
++  case category: data = *_nl_current_##category; break;
++# include categories.def
++# undef DEFINE_CATEGORY
++default:   /* Should be impossible.  */
++  return (char *) ;
++}
++#else
+   data = l-__locales[category];
++#endif
+ 
+   if (index = data-nstrings)
+ /* Bogus index for this category: bogus item.  */
+diff --git a/localedata/Makefile b/localedata/Makefile
+--- a/localedata/Makefile
 b/localedata/Makefile
+@@ -45,7 +45,7 @@
+ 
+ test-srcs := collate-test xfrm-test tst-fmon tst-rpmatch tst-trans \
+tst-mbswcs1 tst-mbswcs2 tst-mbswcs3 tst-mbswcs4 tst-mbswcs5 \
+-   tst-ctype tst-wctype tst-langinfo tst-numeric
++   tst-ctype tst-wctype tst-langinfo tst-langinfo-static tst-numeric
+ test-input := de_DE.ISO-8859-1 en_US.ISO-8859-1 da_DK.ISO-8859-1 \
+ hr_HR.ISO-8859-2 sv_SE.ISO-8859-1 tr_TR.UTF-8 fr_FR.UTF-8 \
+ si_LK.UTF-8
+@@ -164,7 +164,8 @@
+ tests: $(objpfx)sort-test.out $(objpfx)tst-fmon.out $(objpfx)tst-locale.out \
+$(objpfx)tst-rpmatch.out $(objpfx)tst-trans.out \
+$(objpfx)tst-mbswcs.out $(objpfx)tst-ctype.out \
+-   $(objpfx)tst-langinfo.out $(objpfx)tst-numeric.out
++   $(objpfx)tst-langinfo.out $(objpfx)tst-langinfo-static.out\
++   $(objpfx)tst-numeric.out
+ ifeq (y,$(OPTION_POSIX_WIDE_CHAR_DEVICE_IO))
+ tests: $(objpfx)tst-wctype.out
+ endif
+@@ -211,7 +212,11 @@
+ $(objpfx)tst-langinfo.out: tst-langinfo.sh $(objpfx)tst-langinfo \
+   $(objpfx)sort-test.out \
+   $(addprefix $(objpfx),$(CTYPE_FILES))
+-  $(SHELL) $ $(common-objpfx) '$(test-program-cmd)'
++  $(SHELL) $ $(common-objpfx) '$(test-program-cmd)'  $@
++$(objpfx)tst-langinfo-static.out: tst-langinfo.sh 
$(objpfx)tst-langinfo-static \
++  $(objpfx)sort-test.out \
++  $(addprefix $(objpfx),$(CTYPE_FILES))
++  $(SHELL) $ $(common-objpfx) '$(test-program-cmd)' $@
+ $(objpfx)tst-digits.out: $(objpfx)tst-locale.out
+ $(objpfx)tst-mbswcs6.out: $(addprefix $(objpfx),$(CTYPE_FILES))
+ endif
+diff --git a/localedata/tst-langinfo-static.c 
b/localedata/tst-langinfo-static.c
+--- /dev/null
 b/localedata/tst-langinfo-static.c
+@@ -0,0 +1 @@
++#include tst-langinfo.c
+diff --git a/localedata/tst-langinfo.sh b/localedata/tst-langinfo.sh
+--- a/localedata/tst-langinfo.sh
 b/localedata/tst-langinfo.sh
+@@ -340,7 +340,6 @@ ja_JP.EUC-JP 

Processed: Re: [amd64/g++] Suspected toolchain bug causing dlopen to segfault

2014-05-06 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 reassign 723982 tulip
Bug #723982 [src:eglibc] dlopen: segfaults right inside call_init
Bug reassigned from package 'src:eglibc' to 'tulip'.
No longer marked as found in versions eglibc/2.17-92+b1 and eglibc/2.17-97.
Ignoring request to alter fixed versions of bug #723982 to the same values 
previously set
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
723982: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723982
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.c.139940795416134.transcr...@bugs.debian.org



Bug#723982: [amd64/g++] Suspected toolchain bug causing dlopen to segfault

2014-05-06 Thread Aurelien Jarno
reassign 723982 tulip
thanks

On Sat, Feb 01, 2014 at 02:27:49PM +0100, Yann Dirson wrote:
 [resend with bugs CC'd]
 
 Hello,
 
 Context:
 
 http://bugs.debian.org/734318 - tulip: [amd64] segfaults inside dlopen when 
 loading plugins
 http://bugs.debian.org/723982 - dlopen: segfaults right inside call_init
 
 What we get here is a number of plugins that when dlopen'd cause an
 obscure segfault inside libc code.  Upstream (CC'd) say they have
 heard of such problems (on Ubuntu 13.10), that people have worked
 around by downgrading the compiler.
 
 This sounds like either a toolchain regression, or possibly some
 edge-case that worked by chance with old compilers and now fail.

This is exactly that the bug is in tulip and up to know it worked only by 
chance on x86_64. The segfault occurs in dl-init.c when call_init is
calling all the init functions from DT_INIT_ARRAY. This is done in C by
this code:

|  addrs = (ElfW(Addr) *) (init_array-d_un.d_ptr + l-l_addr);
|  for (j = 0; j  jm; ++j)
|((init_t) addrs[j]) (argc, argv, env);

which is translated in assembly code into:

|0x77deb926 +134:   lea0x8(%rbx,%rax,8),%r14
|0x77deb92b +139:   nopl   0x0(%rax,%rax,1)
|0x77deb930 +144:   mov%r13,%rdx
|0x77deb933 +147:   mov%r12,%rsi
|0x77deb936 +150:   mov%ebp,%edi
|0x77deb938 +152:   callq  *(%rbx)
|0x77deb93a +154:   add$0x8,%rbx
|0x77deb93e +158:   cmp%r14,%rbx
|0x77deb941 +161:   jne0x77deb930 call_init+144
|0x77deb943 +163:   pop%rbx
|0x77deb944 +164:   pop%rbp
|0x77deb945 +165:   pop%r12
|0x77deb947 +167:   pop%r13
|0x77deb949 +169:   pop%r14
|0x77deb94b +171:   retq


As you can see the value of addrs is stored in %rbx and is incremented
by 8 at each loop. The segfault occurs at address 0x77deb938
when trying to dereference %rbx. When it happens, %rbx has its upper
32 bits clobbered and thus point to the lower 32-bit of addrs[j].

Tracing that with GDB, it appeared %rbx is clobbered in the System::init
constructor from tulip. This code probes among other things uses the
CPUID instruction using assembly code:

|__asm__ __volatile__ (xchgl%%ebx,%0\n\t
|cpuid  \n\t
|xchgl  %%ebx,%0\n\t
|: +r (b), =a (a), =c 
(c), =d (d)
|: 1 (infoType), 2 (c));

As you can see %ebx is saved with xchgl before the %cpuid instruction
and restored after the same way. While that works correctly on x86, on
x86_64 the 32 upper bits get zeroed. BOOM !

I would suggest to use cpuid.h (which is available since GCC 4.4)
instead of this buggy assembly code to probe the CPU. In the meantime I
am reassigning the bug to tulip.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140506202545.ga8...@volta.rr44.fr



Processed: tagging 747103

2014-05-06 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 tags 747103 + pending
Bug #747103 [libc6-dev] libc6-dev: setlocale in static binary fails
Added tag(s) pending.
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
747103: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747103
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.c.139940854719869.transcr...@bugs.debian.org



Processed: tagging 712157

2014-05-06 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 tags 712157 + pending
Bug #712157 [locales] it_IT locale missing thousands separator
Added tag(s) pending.
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
712157: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712157
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.c.139940855219884.transcr...@bugs.debian.org



Processed: tagging 733237

2014-05-06 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 tags 733237 + pending
Bug #733237 [locales] locales: typo in french traduction 'inappropré'
Added tag(s) pending.
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
733237: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733237
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.c.139940869721030.transcr...@bugs.debian.org



Processed: tagging 741482

2014-05-06 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 tags 741482 + pending
Bug #741482 [libc6] libc6: ptsname_r() can use uninitialized memory
Added tag(s) pending.
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
741482: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741482
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.c.139940866420909.transcr...@bugs.debian.org



Bug#563637: improvements from Ubuntu to handle compiler hardening better

2014-05-06 Thread Aurelien Jarno
On Thu, Feb 11, 2010 at 11:37:10AM -0800, Kees Cook wrote:
 Hi Aurelien,
 
 On Sun, Feb 07, 2010 at 02:13:08PM +0100, Aurelien Jarno wrote:
   I would like to include the following patches that Ubuntu has carried for
   several releases now.  (Note that submitted-leading-zero-stack-guard.diff
   will need to be adjusted slightly if stack-guard-quick-randomization.diff
   is not applied.)
  
  I have applied the two stack protection patches in the Debian package,
  but not the two other ones. See my comments below.
 
 Excellent, thanks!
 
   no-sprintf-pre-truncate.diff
   The sprintf function used when -D_FORTIFY_SOURCE=2 is used incorrectly
   pre-truncates the destination buffer; this changes the long-standing
   expectation of sprintf(foo,%sbaz,foo) to work.  See the patch for
   further discussion.
  
  As explained in the bug report, this code is not valid anyway. If we
  want people to fix their code, we should not workaround the issue. Also
  I am not able to evaluate the impact on the fix, and don't know if it
  may introduce a security bug.
 
 Right, it's incorrect, but around 200 packages[1] use it and expect the
 prior behavior.  I don't feel there is a security issue here, but I can
 respect not wanting to change it.  200 is a pretty small number of
 packages compared to the overall size of the archive.
 
 Perhaps I can re-scan the archive and actually do the mass bug filing.

We are now more than 5 years since the mail with the list of affected
packages, and -D_FORTIFY_SOURCE=2 is now the default, so I guess all
affected packages have been fixed.

   local-fwrite-no-attr-unused.diff
   Again, patch contains discussion, but basically, this disables a
   useless and noisy warning that -D_FORTIFY_SOURCE=2 triggers.
  
  I think people should either not use -D_FORTIFY_SOURCE=2 or fix their
  code. This is a warning anyway. I agree an error can happens up to the
  fclose() call, but it's not an excuse to not check possible errors at
  the fwrite() level. The real bug is actually that fclose() is not marked
  __wur, and that's probably what has to be fixed.
 
 Yeah, I would tend to agree.  The main glitch was that there is no
 compiler option to turn off the warning.  :(

This has been done by upstream in glibc 2.16.

So I guess we could now close this bug. Do you agree?

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140506205604.ga8...@volta.rr44.fr



libc6-dev: setlocale in static binary fails

2014-05-06 Thread Raphael Astier
Hello list,

I'm trying to use setlocale() in a static binary, and I compil with:

$ gcc -Wall -static code.c -o code

When I run
$ ./code

I expect to see lundi instead of Monday, but it's not working with static 
compilation.
(it's ok in dynamic compil. with: $gcc -Wall -code.c -o code).

The locale fr_FR is correctly installed on my system (package locales 
configured with fr_FR).

The code.c is fairly simple :

#include stdio.h
#include locale.h
#include langinfo.h
int main(void)
{
setlocale (LC_ALL, fr_FR);
printf(%s\n,nl_langinfo(DAY_2));
return 0;
}

The problem extends with use of strftime(). 

I have done some debug (with gcc -ggdb) :

- the return of setlocale is correct fr_FR in static and dyn. compil,
- it seems to me that setdata()/setname() in file setlocale.c don't do right 
job (pb with CATEGORY_USED(category))
- I have try use of:
  $ cd tmp ; localedef -i fr_FR -f ISO-8859-1 ./fr_FR
  and put in code.c before setlocale():
  setenv(LOCPATH,/home/raphael/tmp,1);
  but: it's not better in static compilation
- I have noticed with $strace -eopen ./code
  that in dynamic compil : open(/home/raphael/tmp/fr_FR/LC_xxx, O_RDONLY) = 3 
(with setenv)
   open(/usr/lib/locale/locale-archive, 
O_RDONLY|O_LARGEFILE) = 3  (without setenv)
  but in static compil with setenv and setlocale(LC_TIME, fr_FR); nothing is 
opened ...

I have tried this code under different OS :

- RedHat Enterprise Linux Server release 5.5 (Tikanga) or 6  -- it works as 
expected
- Debian Etch, Debian Lenny -- it works as expected
- Debian Wheezy -- the bug is present

Is it possible to do something with libc.a to avoid this bug ?

Thanks,

Raphael
---


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140506210933.GA9035@raph.localdomain



r6050 - in glibc-package/trunk/debian: . patches patches/sparc

2014-05-06 Thread Aurelien Jarno
Author: aurel32
Date: 2014-05-06 22:31:36 + (Tue, 06 May 2014)
New Revision: 6050

Added:
   glibc-package/trunk/debian/patches/sparc/cvs-efd_semaphore.diff
Modified:
   glibc-package/trunk/debian/changelog
   glibc-package/trunk/debian/patches/series
Log:
patches/any/sparc/cvs-efd_semaphore.diff: new patch from upstream to
declare EFD_SEMAPHORE in bits/eventfd.h on SPARC.  Closes: #703559,
#737697.

Modified: glibc-package/trunk/debian/changelog
===
--- glibc-package/trunk/debian/changelog2014-05-06 14:53:47 UTC (rev 
6049)
+++ glibc-package/trunk/debian/changelog2014-05-06 22:31:36 UTC (rev 
6050)
@@ -30,6 +30,9 @@
 socketcall multiplex syscall features detection.  Closes: #730744.
   * patches/any/submitted-nl_langinfo-static.diff: new patch to fix
 nl_langinfo() used in static binaries.  Closes: #747103.
+  * patches/any/sparc/cvs-efd_semaphore.diff: new patch from upstream to
+declare EFD_SEMAPHORE in bits/eventfd.h on SPARC.  Closes: #703559,
+#737697.
 
  -- Adam Conrad adcon...@0c3.net  Sun, 27 Apr 2014 23:15:13 -0600
 

Modified: glibc-package/trunk/debian/patches/series
===
--- glibc-package/trunk/debian/patches/series   2014-05-06 14:53:47 UTC (rev 
6049)
+++ glibc-package/trunk/debian/patches/series   2014-05-06 22:31:36 UTC (rev 
6050)
@@ -199,6 +199,7 @@
 sparc/local-sparcv9-target.diff
 sparc/submitted-timing.diff
 sparc/cvs-strcmp.diff
+sparc/cvs-efd_semaphore.diff
 
 all/local-alias-UTF-8.diff
 all/local-alias-et_EE.diff

Added: glibc-package/trunk/debian/patches/sparc/cvs-efd_semaphore.diff
===
--- glibc-package/trunk/debian/patches/sparc/cvs-efd_semaphore.diff 
(rev 0)
+++ glibc-package/trunk/debian/patches/sparc/cvs-efd_semaphore.diff 
2014-05-06 22:31:36 UTC (rev 6050)
@@ -0,0 +1,18 @@
+2014-05-06  Aurelien Jarno  aurel...@aurel32.net
+
+[BZ #16916]
+* sysdeps/unix/sysv/linux/sparc/bits/eventfd.h (EFD_SEMAPHORE):
+Define.
+
+diff --git a/sysdeps/unix/sysv/linux/sparc/bits/eventfd.h 
b/sysdeps/unix/sysv/linux/sparc/bits/eventfd.h
+--- a/sysdeps/unix/sysv/linux/sparc/bits/eventfd.h
 b/sysdeps/unix/sysv/linux/sparc/bits/eventfd.h
+@@ -22,6 +22,8 @@
+ /* Flags for eventfd.  */
+ enum
+   {
++EFD_SEMAPHORE = 0x01,
++#define EFD_SEMAPHORE EFD_SEMAPHORE
+ EFD_CLOEXEC = 0x40,
+ #define EFD_CLOEXEC EFD_CLOEXEC
+ EFD_NONBLOCK = 0x004000


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1whntg-0001rv...@moszumanska.debian.org



r6051 - in glibc-package/trunk/debian: . patches

2014-05-06 Thread Aurelien Jarno
Author: aurel32
Date: 2014-05-06 22:42:24 + (Tue, 06 May 2014)
New Revision: 6051

Modified:
   glibc-package/trunk/debian/changelog
   glibc-package/trunk/debian/patches/svn-updates.diff
Log:
patches/svn-updates.diff: update from 2.18 branch, to fix a race in free()
of fastbin chunk.

Modified: glibc-package/trunk/debian/changelog
===
--- glibc-package/trunk/debian/changelog2014-05-06 22:31:36 UTC (rev 
6050)
+++ glibc-package/trunk/debian/changelog2014-05-06 22:42:24 UTC (rev 
6051)
@@ -33,6 +33,8 @@
   * patches/any/sparc/cvs-efd_semaphore.diff: new patch from upstream to
 declare EFD_SEMAPHORE in bits/eventfd.h on SPARC.  Closes: #703559,
 #737697.
+  * patches/svn-updates.diff: update from 2.18 branch, to fix a race in free()
+of fastbin chunk.
 
  -- Adam Conrad adcon...@0c3.net  Sun, 27 Apr 2014 23:15:13 -0600
 

Modified: glibc-package/trunk/debian/patches/svn-updates.diff
===
--- glibc-package/trunk/debian/patches/svn-updates.diff 2014-05-06 22:31:36 UTC 
(rev 6050)
+++ glibc-package/trunk/debian/patches/svn-updates.diff 2014-05-06 22:42:24 UTC 
(rev 6051)
@@ -1,8 +1,50 @@
-diff --git a/ChangeLog b/ChangeLog
-index 0dbefe3..1e5efa7 100644
 a/ChangeLog
-+++ b/ChangeLog
-@@ -1,3 +1,19 @@
+SVN update of svn://svn.eglibc.org/branches/eglibc-2_18 from revision 24653
+
+Index: NEWS
+===
+--- a/NEWS (révision 24653)
 b/NEWS (révision 25477)
+@@ -9,7 +9,7 @@
+ 
+ * The following bugs are resolved with this release:
+ 
+-  15909, 15996.
++  15073, 15128, 15909, 15996, 16150, 16169, 16387, 16510.
+ 
+ Version 2.18
+ 
+@@ -28,7 +28,7 @@
+   15429, 15431, 15432, 15441, 15442, 15448, 15465, 15480, 15485, 15488,
+   15490, 15492, 15493, 15497, 15506, 15529, 15536, 15553, 15577, 15583,
+   15618, 15627, 15631, 15654, 15655, 15666, 15667, 15674, 15711, 15755,
+-  15759.
++  15759, 15985.
+ 
+ * CVE-2013-2207 Incorrectly granting access to another user's pseudo-terminal
+   has been fixed by disabling the use of pt_chown (Bugzilla #15755).
+Index: ChangeLog
+===
+--- a/ChangeLog(révision 24653)
 b/ChangeLog(révision 25477)
+@@ -1,3 +1,37 @@
++2014-01-29  H.J. Lu  hongjiu...@intel.com
++
++  [BZ #16510]
++  * sysdeps/x86/fpu/bits/mathinline.h: Check __SSE2_MATH__ instead
++  of __x86_64__ when disabling x87 inline functions.
++
++2014-01-20  H.J. Lu  hongjiu...@intel.com
++
++  [BZ #15605]
++  * sysdeps/x86_64/x32/symbol-hacks.h: Include generic symbol-hacks.h.
++
++2014-01-04  Maxim Kuvyrkov  ma...@kugelworks.com
++  Ondřej Bílka  nel...@seznam.cz
++
++  [BZ #15073]
++  * malloc/malloc.c (_int_free): Perform sanity check only if we
++have_lock.
++
 +2013-11-11  David S. Miller  da...@davemloft.net
 +
 +  [BZ #16150]
@@ -22,46 +64,151 @@
  2013-09-06  David S. Miller  da...@davemloft.net
  
* po/zh_TW.po: Update Chinese (traditional) translation from
-diff --git a/NEWS b/NEWS
-index fb6069d..df97235 100644
 a/NEWS
-+++ b/NEWS
-@@ -9,7 +9,7 @@ Version 2.18.1
+Index: sysdeps/x86/fpu/bits/mathinline.h
+===
+--- a/sysdeps/x86/fpu/bits/mathinline.h(révision 24653)
 b/sysdeps/x86/fpu/bits/mathinline.h(révision 25477)
+@@ -1,5 +1,5 @@
+ /* Inline math functions for i387 and SSE.
+-   Copyright (C) 1995-2013 Free Software Foundation, Inc.
++   Copyright (C) 1995-2014 Free Software Foundation, Inc.
+This file is part of the GNU C Library.
  
- * The following bugs are resolved with this release:
+The GNU C Library is free software; you can redistribute it and/or
+@@ -384,7 +384,7 @@
+ # endif
+ #endif
  
--  15909, 15996.
-+  15909, 15996, 16150.
- 
- Version 2.18
+-#ifndef __x86_64__
++#ifndef __SSE2_MATH__
+ # if ((!defined __NO_MATH_INLINES || defined __LIBC_INTERNAL_MATH_INLINES) \
+   defined __OPTIMIZE__)
  
-@@ -28,7 +28,7 @@ Version 2.18
-   15429, 15431, 15432, 15441, 15442, 15448, 15465, 15480, 15485, 15488,
-   15490, 15492, 15493, 15497, 15506, 15529, 15536, 15553, 15577, 15583,
-   15618, 15627, 15631, 15654, 15655, 15666, 15667, 15674, 15711, 15755,
--  15759.
-+  15759, 15985.
+@@ -970,4 +970,4 @@
+   return __value;)
+ # endif
  
- * CVE-2013-2207 Incorrectly granting access to another user's pseudo-terminal
-   has been fixed by disabling the use of pt_chown (Bugzilla #15755).
-diff --git a/ports/ChangeLog.alpha b/ports/ChangeLog.alpha
-index 4a4db09..0fc0a4b 100644
 a/ports/ChangeLog.alpha
-+++ b/ports/ChangeLog.alpha
-@@ -1,3 +1,8 @@
-+2013-11-16  Richard Henderson  r...@redhat.com
-+
-+  * sysdeps/unix/sysv/linux/alpha/rt_sigaction.S: Include a nop
-+  before each signal thunk.
-+
- 2013-07-02  Richard 

r6052 - glibc-package/trunk/debian

2014-05-06 Thread Aurelien Jarno
Author: aurel32
Date: 2014-05-06 22:43:14 + (Tue, 06 May 2014)
New Revision: 6052

Modified:
   glibc-package/trunk/debian/changelog
Log:
Fix bug number



Modified: glibc-package/trunk/debian/changelog
===
--- glibc-package/trunk/debian/changelog2014-05-06 22:42:24 UTC (rev 
6051)
+++ glibc-package/trunk/debian/changelog2014-05-06 22:43:14 UTC (rev 
6052)
@@ -31,7 +31,7 @@
   * patches/any/submitted-nl_langinfo-static.diff: new patch to fix
 nl_langinfo() used in static binaries.  Closes: #747103.
   * patches/any/sparc/cvs-efd_semaphore.diff: new patch from upstream to
-declare EFD_SEMAPHORE in bits/eventfd.h on SPARC.  Closes: #703559,
+declare EFD_SEMAPHORE in bits/eventfd.h on SPARC.  Closes: #730092,
 #737697.
   * patches/svn-updates.diff: update from 2.18 branch, to fix a race in free()
 of fastbin chunk.


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1who4w-0005hu...@moszumanska.debian.org