r4105 - in glibc-package/trunk/debian: . patches patches/hurd-i386

2010-01-26 Thread Samuel Thibault 
Author: sthibault
Date: 2010-01-26 10:17:12 + (Tue, 26 Jan 2010)
New Revision: 4105

Added:
   glibc-package/trunk/debian/patches/hurd-i386/submitted-getnprocs.diff
Modified:
   glibc-package/trunk/debian/changelog
   glibc-package/trunk/debian/patches/series
Log:
patches/hurd-i386/submitted-getnprocs.diff: New patch to add get_nprocs() and 
such weak aliases.


Modified: glibc-package/trunk/debian/changelog
===
--- glibc-package/trunk/debian/changelog2010-01-25 16:27:31 UTC (rev 
4104)
+++ glibc-package/trunk/debian/changelog2010-01-26 10:17:12 UTC (rev 
4105)
@@ -21,6 +21,8 @@
   * patches/hurd-i386/submitted-sysvshm.diff: Resync.
   * patches/hurd-i386/submitted-net.diff: New patch to factorize net/ files
 between Linux and Hurd.
+  * patches/hurd-i386/submitted-getnprocs.diff: New patch to add get_nprocs()
+and such weak aliases.
 
  -- Aurelien Jarno   Sat, 23 Jan 2010 18:27:05 +0100
 

Added: glibc-package/trunk/debian/patches/hurd-i386/submitted-getnprocs.diff
===
--- glibc-package/trunk/debian/patches/hurd-i386/submitted-getnprocs.diff   
(rev 0)
+++ glibc-package/trunk/debian/patches/hurd-i386/submitted-getnprocs.diff   
2010-01-26 10:17:12 UTC (rev 4105)
@@ -0,0 +1,42 @@
+2010-01-26  Samuel Thibault  
+
+   * sysdeps/mach/getsysstats.c (get_nprocs_conf, get_nprocs,
+   get_phys_pages, get_avphys_pages): Add weak aliases.
+
+---
+ getsysstats.c |4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/sysdeps/mach/getsysstats.c b/sysdeps/mach/getsysstats.c
+index d2bebb6..a7e0804 100644
+--- a/sysdeps/mach/getsysstats.c
 b/sysdeps/mach/getsysstats.c
+@@ -40,6 +40,7 @@ __get_nprocs_conf ()
+ 
+   return hbi.max_cpus;
+ }
++weak_alias (__get_nprocs_conf, get_nprocs_conf)
+ 
+ /* Return the number of processors currently available on the system. */
+ int
+@@ -58,6 +59,7 @@ __get_nprocs ()
+ 
+   return hbi.avail_cpus;
+ }
++weak_alias (__get_nprocs, get_nprocs)
+ 
+ /* Return the number of physical pages on the system. */
+ long int
+@@ -76,6 +78,7 @@ __get_phys_pages ()
+ 
+   return hbi.memory_size / __vm_page_size;
+ }
++weak_alias (__get_phys_pages, get_phys_pages)
+ 
+ /* Return the number of available physical pages */
+ long int
+@@ -100,3 +103,4 @@ __get_avphys_pages ()
+ 
+   return vs.free_count;
+ }
++weak_alias (__get_avphys_pages, get_avphys_pages)

Modified: glibc-package/trunk/debian/patches/series
===
--- glibc-package/trunk/debian/patches/series   2010-01-25 16:27:31 UTC (rev 
4104)
+++ glibc-package/trunk/debian/patches/series   2010-01-26 10:17:12 UTC (rev 
4105)
@@ -114,6 +114,7 @@
 hurd-i386/cvs-getcwd.diff
 hurd-i386/cvs-setsid.diff
 hurd-i386/submitted-net.diff
+hurd-i386/submitted-getnprocs.diff
 
 ia64/submitted-sysconf.diff
 ia64/submitted-libm.diff


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#566947: emacs23-nox fails to install

2010-01-26 Thread Sven Joachim 
[ Putting the glibc maintainers and the mips porters into the loop.
  Summary: emacs23-nox aborts with malloc assertion failure on mipsel. ]

On 2010-01-26 02:17 +0100, Deng Xiyue wrote:

> Package: emacs23-nox
> Version: 23.1+1-5
> Severity: grave
>
> When installing emacs23-nox, aptitude stops with the following outputs:
>
> ---BEGIN OF OUTPUT---
>
> $ LANG=C sudo aptitude install emacs23-nox
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Reading extended state information
> Initializing package states... Done
> Reading task descriptions... Done
> The following partially installed packages will be configured:
>   emacs23-nox
> 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Need to get 0B of archives. After unpacking 0B will be used.
> Writing extended state information... Done
> Setting up emacs23-nox (23.1+1-5) ...
> emacs-install emacs23
> install/cscope: Byte-compiling for emacs23
> emacs23: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char 
> *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, 
> fd && old_size == 0) || ((unsigned long) (old_size) >= (unsigned 
> long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * 
> (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size 
> & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.
> Fatal error (6)Aborted

This assertion failure happens in libc6.  I'm inclined to reassign the
bug, but I'll leave this to more knowledgeable people.  The fact that
the eglibc testsuite is currently disabled on mipsel¹ does not exactly
increase confidence in the libc6 package on that architecture.

> install/dictionaries-common: Byte-compiling for emacsen flavour emacs23
> emacs23: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char 
> *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, 
> fd && old_size == 0) || ((unsigned long) (old_size) >= (unsigned 
> long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * 
> (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size 
> & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.
> Fatal error (6)Aborted
> emacsen-common: Handling install of emacsen flavor emacs23
> emacsen-common: byte-compiling for emacs23
> emacs23: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char 
> *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, 
> fd && old_size == 0) || ((unsigned long) (old_size) >= (unsigned 
> long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * 
> (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size 
> & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.
> Fatal error (6)Aborted
> emacs-install: /usr/lib/emacsen-common/packages/install/emacsen-common 
> emacs23 failed at /usr/lib/emacsen-common/emacs-install line 28,  line 
> 6.
> dpkg: error processing emacs23-nox (--configure):
>  subprocess installed post-installation script returned error exit status 134
> Errors were encountered while processing:
>  emacs23-nox
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> A package failed to install.  Trying to recover:
> Setting up emacs23-nox (23.1+1-5) ...
> emacs-install emacs23
> install/cscope: Byte-compiling for emacs23
> emacs23: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char 
> *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, 
> fd && old_size == 0) || ((unsigned long) (old_size) >= (unsigned 
> long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * 
> (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size 
> & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.
> Fatal error (6)Aborted
> install/dictionaries-common: Byte-compiling for emacsen flavour emacs23
> emacs23: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char 
> *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, 
> fd && old_size == 0) || ((unsigned long) (old_size) >= (unsigned 
> long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * 
> (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size 
> & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.
> Fatal error (6)Aborted
> emacsen-common: Handling install of emacsen flavor emacs23
> emacsen-common: byte-compiling for emacs23
> emacs23: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char 
> *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, 
> fd && old_size == 0) || ((unsigned long) (old_size) >= (unsigned 
> long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * 
> (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size 
> & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.
> Fat

Re: Bug#566947: emacs23-nox fails to install

2010-01-26 Thread Aurelien Jarno 
Sven Joachim a écrit :
> [ Putting the glibc maintainers and the mips porters into the loop.
>   Summary: emacs23-nox aborts with malloc assertion failure on mipsel. ]
> 
> On 2010-01-26 02:17 +0100, Deng Xiyue wrote:
> 
>> Package: emacs23-nox
>> Version: 23.1+1-5
>> Severity: grave
>>
>> When installing emacs23-nox, aptitude stops with the following outputs:
>>
>> ---BEGIN OF OUTPUT---
>>
>> $ LANG=C sudo aptitude install emacs23-nox
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> Reading extended state information
>> Initializing package states... Done
>> Reading task descriptions... Done
>> The following partially installed packages will be configured:
>>   emacs23-nox
>> 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>> Need to get 0B of archives. After unpacking 0B will be used.
>> Writing extended state information... Done
>> Setting up emacs23-nox (23.1+1-5) ...
>> emacs-install emacs23
>> install/cscope: Byte-compiling for emacs23
>> emacs23: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) 
>> (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct 
>> malloc_chunk, fd && old_size == 0) || ((unsigned long) (old_size) >= 
>> (unsigned long)__builtin_offsetof (struct malloc_chunk, 
>> fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 
>> 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 
>> 0)' failed.
>> Fatal error (6)Aborted

I don't have this failure here when trying to install emacs23 (cscope is
also installed). Do you know if there are some more conditions to
trigger this bug?

Also, it looks like a memory corruption. Have you tried to reboot the
machine? A different kernel?

> This assertion failure happens in libc6.  I'm inclined to reassign the
> bug, but I'll leave this to more knowledgeable people.  The fact that
> the eglibc testsuite is currently disabled on mipsel¹ does not exactly
> increase confidence in the libc6 package on that architecture.

The testsuite has been disabled due to broken buildds, not due to a
broken package. It is actually run when build on a different machines
than the build daemons, and it passes without any problem, provided you
have a recent kernel (lenny one for example).

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
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

Re: Bug#563882: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails

2010-01-26 Thread Jonathan Nieder 
reassign 563882 libc6.1 2.10.2-5
severity 563882 critical
retitle 563882 ia64: mmap reading null bytes that should not be there
thanks

Hi libc maintainers,

mmap() on ia64 seems to be totally broken.  git does something
like the following to detect binary files:

struct stat st;
lstat(path, &st);
int fd = open(path, O_RDONLY);
void *data = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
binary = !!memchr(data, 0, st.st_size);
munmap(data, st.st_size);

That is, it maps the file into memory and looks for null bytes.

Unfortunately, the test suite when run on merulo and mundy revealed
that this was detecting various text files as binary.  When mmapping
two files in sequence, only the first seems to have this problem.

Test case attached.  Usage: compile with

gcc -Wall -W -O -o generic-is-binary generic-is-binary.c

Take your favorite text file M.out (see
 and search for "-- %< -- M.out" for
the example Andreas used to reproduce this) and run

 (no description available)
| ametz...@merulo:/tmp$ dpkg -l libc6.1
[...]
| ii  libc6.12.10.2-5   Embedded GNU C Library: Shared libraries
| ametz...@merulo:/tmp$ gcc -Wall -W -O -o generic-is-binary generic-is-binary.c
| ametz...@merulo:/tmp$ popd
| /tmp/GIT/git-core-1.6.6-debug/t/trash directory.t1001-read-tree-m-2way
| ametz...@merulo:/tmp/GIT/git-core-1.6.6-debug/t/trash 
directory.t1001-read-tree-m-2way$ http://bugs.debian.org/563882 for the full story.

This regression came in October of last year on caballero. [1] Any ideas?

Andreas Metzler wrote:
> okay:
> ametz...@merulo:/tmp/GIT/git-core-1.6.6-debug/t/trash 
> directory.t1001-read-tree-m-2way$ <4.out 
> /tmp/GIT/git-core-1.6.6-debug/git-is-binary 4.out M.out
> static buffer is not binary
> stdin is not binary
> 4.out is binary
> M.out is not binary
> ametz...@merulo:/tmp/GIT/git-core-1.6.6-debug/t/trash 
> directory.t1001-read-tree-m-2way$ cp M.out M2.out
> ametz...@merulo:/tmp/GIT/git-core-1.6.6-debug/t/trash 
> directory.t1001-read-tree-m-2way$ <4.out 
> /tmp/GIT/git-core-1.6.6-debug/git-is-binary M.out M2.out
> static buffer is not binary
> stdin is not binary
> M.out is binary
> M2.out is not binary
> ametz...@merulo:/tmp/GIT/git-core-1.6.6-debug/t/trash 
> directory.t1001-read-tree-m-2way$  /tmp/GIT/git-core-1.6.6-debug/git-is-binary M.out M2.out
> static buffer is not binary
> stdin is not binary
> M.out is binary
> M2.out is not binary

Ugh, so it’s always the first mmap...

>> If M.out (but not stdin) is reported to be binary, great: git is
>> exonerated, and we have an independent test case.
>
> You win. ;-)

Thank you!

Reassigning to libc.  I will leave the rest of the debugging to someone
more knowledgeable about ia64/libc/linux-2.6. ;-)

Thank you for your help tracking this down.  You’ve had the patience
of a saint.

Regards,
Jonathan

[1] https://buildd.debian.org/build.php?&pkg=git-core&arch=ia64
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

static int xprintf(const char *fmt, ...);
static int buffer_is_binary(const char *ptr, size_t size);
static int check_stdin(void);
static int check_file(const char *path);

int main(int argc, const char * const argv[])
{
	int result = 0;

	if (argc != 2) {
		fprintf(stderr, "usage: generic-is-binary  < \n");
		exit(1);
	}

	result |= check_stdin();
	result |= check_file(argv[1]);
	return result;
}

static int buffer_is_binary(const char *ptr, size_t sz)
{
	return !!memchr(ptr, 0, sz);
}

static int check_stdin(void)
{
	static char in_buf[8000];
	char *bufp = in_buf;
	char *buf_end = in_buf + sizeof(in_buf);
	ssize_t n;

	while ((n = read(0, bufp, buf_end - bufp))) {
		if (n < 0) {
			perror("stdin: read");
			return -1;
		}
		bufp += n;
	}

	return xprintf("stdin is%s binary\n",
		buffer_is_binary(in_buf, bufp - in_buf) ?
		"" : " not");
}

static ssize_t size(const char *path)
{
	struct stat st;
	if (lstat(path, &st) < 0) {
		fprintf(stderr, "%s: lstat: %s\n",
			path, strerror(errno));
		return -1;
	}
	return st.st_size;
}

static int check_file(const char *path)
{
	ssize_t sz;
	int fd, result;
	void *data;

	if ((sz = size(path)) < 0)
		return -1;
	if ((fd = open(path, O_RDONLY)) < 0) {
		fprintf(stderr, "%s: open: %s\n",
			path, strerror(errno));
		return -1;
	}
	data = mmap(NULL, sz, PROT_READ, MAP_PRIVATE, fd, 0);
	if (data == MAP_FAILED) {
		fprintf(stderr, "%s: mmap: %s\n",
			path, strerror(errno));
		close(fd);
		return -1;
	}
	if (close(fd)) {
		fprintf(stderr, "%s: close: %s\n",
			path, strerror(errno));
		return -1;
	}

	result = xprintf("%s is%s binary\n",
		path,
		buffer_is_binary(data, sz) ?
		"" : " not");

	if (munmap(data, sz)) {
		fprintf(stderr, "%s: munmap: %s\n",
			path, strerror(errno));
		return -1;
	}
	return result;
}

static int xprintf(const char *fmt, ...)
{
	int result = 0;

	va_list ap;
	va_start(ap, fmt);
	if (vprintf(fmt, ap

Processed: Re: Bug#563882: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails

2010-01-26 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> reassign 563882 libc6.1 2.10.2-5
Bug #563882 [git-core] git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test 
fails
Bug reassigned from package 'git-core' to 'libc6.1'.
Bug No longer marked as found in versions git-core/1:1.6.5.2-1.
Bug #563882 [libc6.1] git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test 
fails
Bug Marked as found in versions eglibc/2.10.2-5.
> severity 563882 critical
Bug #563882 [libc6.1] git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test 
fails
Severity set to 'critical' from 'serious'

> retitle 563882 ia64: mmap reading null bytes that should not be there
Bug #563882 [libc6.1] git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test 
fails
Changed Bug title to 'ia64: mmap reading null bytes that should not be there' 
from 'git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails'
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: Re: ia64: mmap reading null bytes that should not be there

2010-01-26 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> # has a workaround patch, not a fix for libc
> tags 563882 - patch
Bug #563882 [libc6.1] ia64: mmap reading null bytes that should not be there
Removed tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: Re: Bug#563882: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails

2010-01-26 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> severity 563882 important
Bug #563882 [libc6.1] ia64: mmap reading null bytes that should not be there
Severity set to 'important' from 'critical'

> retitle 563882 ia64: memchr overshots
Bug #563882 [libc6.1] ia64: mmap reading null bytes that should not be there
Changed Bug title to 'ia64: memchr overshots' from 'ia64: mmap reading null 
bytes that should not be there'
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#563882: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails

2010-01-26 Thread Bastian Blank 
severity 563882 important
retitle 563882 ia64: memchr overshots
thanks

On Tue, Jan 26, 2010 at 01:48:34PM -0600, Jonathan Nieder wrote:
> severity 563882 critical

Please explain. git is neither unrelated to glibc nor does this cause
serious data loss.

> That is, it maps the file into memory and looks for null bytes.

No, the kernel always maps complete pages, so this maps several null
bytes.

> Then this program would lie to you and say “M.out is binary”

The test program does not properly show what is going on.

The following program shows the cause:

| #include 
| #include 
| #include 
| 
| int main(int argc, const char * const argv[])
| { 
|   struct stat st;
|   lstat(argv[1], &st);
| 
|   int fd = open(argv[1], O_RDONLY);
|   void *data = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
|   void *t = memchr(data, 0, st.st_size);
|   printf("ptr: %p, ret: %p, len: 0x%zx\n", data, t, st.st_size);
|   return 0;
| }

Example output:
| % ./test /etc/passwd
| ptr: 0x2005, ret: 0x2005040e, len: 0x40e

The found location is already after the buffer. memchr is AFAIK expanded
by gcc.

Bastian

-- 
Where there's no emotion, there's no motive for violence.
-- Spock, "Dagger of the Mind", stardate 2715.1



--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#563882: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails

2010-01-26 Thread Jonathan Nieder 
Bastian Blank wrote:

> On Tue, Jan 26, 2010 at 01:48:34PM -0600, Jonathan Nieder wrote:
> > severity 563882 critical
> 
> Please explain. git is neither unrelated to glibc nor does this cause
> serious data loss.

My mistake, sorry about that.

> The test program does not properly show what is going on.
> 
> The following program shows the cause:
> 
> | #include 
> | #include 
> | #include 
> | 
> | int main(int argc, const char * const argv[])
> | { 
> |   struct stat st;
> |   lstat(argv[1], &st);
> | 
> |   int fd = open(argv[1], O_RDONLY);
> |   void *data = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
> |   void *t = memchr(data, 0, st.st_size);
> |   printf("ptr: %p, ret: %p, len: 0x%zx\n", data, t, st.st_size);
> |   return 0;
> | }
> 
> Example output:
> | % ./test /etc/passwd
> | ptr: 0x2005, ret: 0x2005040e, len: 0x40e
> 
> The found location is already after the buffer. memchr is AFAIK expanded
> by gcc.

Thanks for the clear test case.

Given gcc -S output, I would gladly look it over.

Regards,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#563882: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails

2010-01-26 Thread Jonathan Nieder 
Bastian Blank wrote:

> The following program shows the cause:
> 
> | #include 
> | #include 
> | #include 
> | 
> | int main(int argc, const char * const argv[])
> | { 
> |   struct stat st;
> |   lstat(argv[1], &st);
> | 
> |   int fd = open(argv[1], O_RDONLY);
> |   void *data = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
> |   void *t = memchr(data, 0, st.st_size);
> |   printf("ptr: %p, ret: %p, len: 0x%zx\n", data, t, st.st_size);
> |   return 0;
> | }
> 
> Example output:
> | % ./test /etc/passwd
> | ptr: 0x2005, ret: 0x2005040e, len: 0x40e
> 
> The found location is already after the buffer. memchr is AFAIK expanded
> by gcc.

FYI: http://sourceware.org/bugzilla/show_bug.cgi?id=10162
Maybe glibc 2.11.1 (which includes a cherry-pick of commit 6622141)
will fix this.

I checked gcc’s memchr builtin; there is no ia64-specific version,
and the generic code just deals with constants and delegates the
real work to libc memchr.

Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#566947: emacs23-nox fails to install

2010-01-26 Thread Deng Xiyue 
On Tue, Jan 26, 2010 at 01:39:24PM +0100, Sven Joachim wrote:
> > Versions of packages emacs23-nox depends on:
> > ii  emacs23-bin-common23.1+1-5   The GNU Emacs editor's shared, 
> > arc
> > ii  install-info  4.13a.dfsg.1-5 Manage installed documentation 
> > in 
> > ii  libasound21.0.21a-1  shared library for ALSA 
> > applicatio
> > ii  libc6 2.10.2-2   GNU C Library: Shared libraries
> 
> It will probably not help, but could you please upgrade libc6 to the
> version in unstable (2.10.2-5) and retry?
>

As you expected, upgrading libc6 to unstable version (2.10.2-5) doesn't
help.

> Regards,
> Sven
> 
> 
> ¹ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516087


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#563882: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails

2010-01-26 Thread Aurelien Jarno 
On Tue, Jan 26, 2010 at 04:06:32PM -0600, Jonathan Nieder wrote:
> Bastian Blank wrote:
> 
> > The following program shows the cause:
> > 
> > | #include 
> > | #include 
> > | #include 
> > | 
> > | int main(int argc, const char * const argv[])
> > | { 
> > |   struct stat st;
> > |   lstat(argv[1], &st);
> > | 
> > |   int fd = open(argv[1], O_RDONLY);
> > |   void *data = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
> > |   void *t = memchr(data, 0, st.st_size);
> > |   printf("ptr: %p, ret: %p, len: 0x%zx\n", data, t, st.st_size);
> > |   return 0;
> > | }
> > 
> > Example output:
> > | % ./test /etc/passwd
> > | ptr: 0x2005, ret: 0x2005040e, len: 0x40e
> > 
> > The found location is already after the buffer. memchr is AFAIK expanded
> > by gcc.
> 
> FYI: http://sourceware.org/bugzilla/show_bug.cgi?id=10162
> Maybe glibc 2.11.1 (which includes a cherry-pick of commit 6622141)
> will fix this.
> 

This patch is already included in the Debian libc6 package. It actually
may be the cause of the problem you reported.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
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

Re: Bug#566947: emacs23-nox fails to install

2010-01-26 Thread Deng Xiyue 
On Tue, Jan 26, 2010 at 05:44:53PM +0100, Aurelien Jarno wrote:
> Sven Joachim a écrit :
> > [ Putting the glibc maintainers and the mips porters into the loop.
> >   Summary: emacs23-nox aborts with malloc assertion failure on mipsel. ]
> > 
> > On 2010-01-26 02:17 +0100, Deng Xiyue wrote:
> > 
> >> Package: emacs23-nox
> >> Version: 23.1+1-5
> >> Severity: grave
> >>
> >> When installing emacs23-nox, aptitude stops with the following outputs:
> >>
> >> ---BEGIN OF OUTPUT---
> >>
> >> $ LANG=C sudo aptitude install emacs23-nox
> >> Reading package lists... Done
> >> Building dependency tree
> >> Reading state information... Done
> >> Reading extended state information
> >> Initializing package states... Done
> >> Reading task descriptions... Done
> >> The following partially installed packages will be configured:
> >>   emacs23-nox
> >> 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> >> Need to get 0B of archives. After unpacking 0B will be used.
> >> Writing extended state information... Done
> >> Setting up emacs23-nox (23.1+1-5) ...
> >> emacs-install emacs23
> >> install/cscope: Byte-compiling for emacs23
> >> emacs23: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) 
> >> (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct 
> >> malloc_chunk, fd && old_size == 0) || ((unsigned long) (old_size) >= 
> >> (unsigned long)__builtin_offsetof (struct malloc_chunk, 
> >> fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 
> >> 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 
> >> 0)' failed.
> >> Fatal error (6)Aborted
> 
> I don't have this failure here when trying to install emacs23 (cscope is
> also installed). Do you know if there are some more conditions to
> trigger this bug?
> 

Actually, installing package "emacs23" works fine, only installing
emacs23-nox fails with the above assertion.

> Also, it looks like a memory corruption. Have you tried to reboot the
> machine? A different kernel?
> 

I have tried rebooting, no luck.  Installing on my amd64 sid virtual
machine works without problem, so looks like it is mips* specific.

FYI, this is a loongson2f laptop, so both the kernel and binutils have
been patched to work with this kind of machine, and related patches are
being review for integration with upstream kernel source.  I don't know
whether those patches have any impact on this problem.

> > This assertion failure happens in libc6.  I'm inclined to reassign the
> > bug, but I'll leave this to more knowledgeable people.  The fact that
> > the eglibc testsuite is currently disabled on mipsel¹ does not exactly
> > increase confidence in the libc6 package on that architecture.
> 
> The testsuite has been disabled due to broken buildds, not due to a
> broken package. It is actually run when build on a different machines
> than the build daemons, and it passes without any problem, provided you
> have a recent kernel (lenny one for example).
> 
> -- 
> Aurelien Jarno  GPG: 1024D/F1BCDB73
> 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