Bug#219769: libc6-2.3.2.ds1-10 on ARM breaks modutils
on Sat, Nov 08, 2003 at 08:43:07PM -0800, Jeff Bailey wrote: I was hoping to wait until BenC (or another Sparc porter) came up with the solution for the sparc64 borkage. Okay. I've uploaded 2.3.2.ds1-10.0.1 as a binary NMU. It seems to fix the modutils problem. p.
Processing of glibc_2.3.2.ds1-10.0.1_arm.changes
glibc_2.3.2.ds1-10.0.1_arm.changes isn't signed with PGP/GnuPG Removing glibc_2.3.2.ds1-10.0.1_arm.changes, but keeping its associated files for now. Greetings, Your Debian queue daemon
Bug#216921: other problems related to bug 216921
Hello, I upgraded to today's unstable and it seems there are other errors again: In file included from /usr/include/asm/sigcontext.h:4, from /usr/include/bits/sigcontext.h:28, from /usr/include/signal.h:326, from /home/damien/tt/Asterisk/pwlib/include/ptlib/unix/ptlib/pmachdep.h:167, from /home/damien/tt/Asterisk/pwlib/include/ptlib/unix/ptlib/contain.h:61, from /home/damien/tt/Asterisk/pwlib/include/ptlib/../ptlib.h:146, from common.h:45, from ldap_window.h:43, from callbacks.cpp:42: /usr/include/linux/compiler.h:17: warning: `__attribute_used__' redefined /usr/include/sys/cdefs.h:195: warning: this is the location of the previous definition In file included from /home/damien/tt/Asterisk/pwlib/include/ptlib/../ptlib.h:169, -- _ Damien Sandras (o- //\ It-Optics s.a. v_/_GnomeMeeting: http://www.gnomemeeting.org/ FOSDEM 2004: http://www.fosdem.org H.323 phone: callto:ils.seconix.com/[EMAIL PROTECTED]
Bug#216921: other problems related to bug 216921
Apparently it only appears with g++-2.95.4. g++ 3.3 doesn't give that kind of problem. -- _ Damien Sandras (o- //\ It-Optics s.a. v_/_GnomeMeeting: http://www.gnomemeeting.org/ FOSDEM 2004: http://www.fosdem.org H.323 phone: callto:ils.seconix.com/[EMAIL PROTECTED]
Bug#219943: Additional useful information regarding libc6 (2.3.2.ds1-*) and Nvidia GL[X] libs
Duck, This is an installer problem, not a libc6 problem. To verify, download the x86 Nvidia 1.0-4496 installer from Nvidia's website, edit the top- level Makefile's install: target (remove kernel_module_install from the end of the line), then run make install. Verify that /usr/lib/tls/libGL* exist. I'm also appending MD5sums of the relevant binaries from 1.0-4496. 060b4cd6db19e26e995f523c3fa8bbdf /usr/lib/tls/libGL.so.1.0.4496 35c680fcbb0ce38bc246cacbb38eabb1 /usr/lib/tls/libGLcore.so.1.0.4496 ac85f1f9908f94282ed14a526fb319e1 /usr/X11R6/lib/modules/extensions/libglx.so.1.0.4496 That is the procedure I followed during the libc6 upgrade. Hope this helps. -D -- Daniel T. Chen [EMAIL PROTECTED] GPG key: www.sh.nu/~crimsun/pubkey.gpg.asc pgpZv2THfwOGw.pgp Description: PGP signature
Bug#219352: xmms libc crash
At Tue, 11 Nov 2003 20:23:58 +0100, Felix Seeger wrote: On Tuesday 11 November 2003 18:19, Juergen Kreileder wrote: Jeff Bailey [EMAIL PROTECTED] writes: On Wed, Nov 12, 2003 at 12:49:38AM +0900, GOTO Masanori wrote: I also tested on both 2.4 and 2.6 kernel, even with removing ~/.xmms. However I cannot reproduce it... Which CPU do you use? I use an AMD Athlon XP 2500+ on an Asus nforce2 board with nvidia drivers. I also cannot reproduce 2.4 kernel on k7 using Debian's package, and Pentium 2 Xeon, using Debian's 2.6.0-test9 kernel package. The original bug report says Unless libmikmod2 is installed [...]. (xmms recommends libmikmod2.) If I move /usr/lib/libmikmod.so.2* out of the way I can reproduce this problem with 2.6.0-test9-mm2: Yes, if I install libmikmod2 xmms starts up normally. This problem is occured under: - kernel 2.6.0-test9 - glibc 2.3.2.ds1-9 - CPU is not related? - xmms 1.2.8-2 - libmikmod 3.1.10-5 - you might not install libc6-i686 - we use unstable sid. I use such environment, but I cannot reproduce this problem... Please check your environment settings, and if you can, please track with gdb and strace. This bug may be downgraded to important... Regards, -- gotom
Bug#219352: xmms libc crash
On Thursday 13 November 2003 02:11, GOTO Masanori wrote:
At Tue, 11 Nov 2003 20:23:58 +0100,
Felix Seeger wrote:
On Tuesday 11 November 2003 18:19, Juergen Kreileder wrote:
Jeff Bailey [EMAIL PROTECTED] writes:
On Wed, Nov 12, 2003 at 12:49:38AM +0900, GOTO Masanori wrote:
I also tested on both 2.4 and 2.6 kernel, even with removing
~/.xmms. However I cannot reproduce it... Which CPU do you use?
I use an AMD Athlon XP 2500+ on an Asus nforce2 board with nvidia
drivers.
I also cannot reproduce 2.4 kernel on k7 using Debian's package, and
Pentium 2 Xeon, using Debian's 2.6.0-test9 kernel package.
The original bug report says Unless libmikmod2 is installed [...].
(xmms recommends libmikmod2.)
If I move /usr/lib/libmikmod.so.2* out of the way I can reproduce
this problem with 2.6.0-test9-mm2:
Yes, if I install libmikmod2 xmms starts up normally.
This problem is occured under:
- kernel 2.6.0-test9
- glibc 2.3.2.ds1-9
2.3.2.ds1-10, but I think it also happend with -9
- CPU is not related?
Don't know
- xmms 1.2.8-2
- libmikmod 3.1.10-5
If not installed
- you might not install libc6-i686
yes, not installed
- we use unstable sid.
yes
I use such environment, but I cannot reproduce this problem... Please
check your environment settings, and if you can, please track with gdb
and strace. This bug may be downgraded to important...
I remove libmikmod2 and run xmms with gdb, but when I type bt, there isn't
one. Here is the strace output from the libmikmod warning on:
write(2, libmikmod.so.2: cannot open shar..., 74libmikmod.so.2: cannot open
shared object file: No such file or directory
) = 74
stat64(/usr/lib/xmms/Input/libcdaudio.so, {st_mode=S_IFREG|0644,
st_size=55440, ...}) = 0
open(/usr/lib/xmms/Input/libcdaudio.so, O_RDONLY) = 8
read(8, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 2\0\000..., 512) =
512
fstat64(8, {st_mode=S_IFREG|0644, st_size=55440, ...}) = 0
old_mmap(NULL, 56736, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) = 0x4109c000
old_mmap(0x410a9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 8,
0xd000) = 0x410a9000
close(8)= 0
stat64(/usr/lib/xmms/Input/libtonegen.so, {st_mode=S_IFREG|0644,
st_size=8508, ...}) = 0
open(/usr/lib/xmms/Input/libtonegen.so, O_RDONLY) = 8
read(8, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\t\0..., 512) =
512
fstat64(8, {st_mode=S_IFREG|0644, st_size=8508, ...}) = 0
old_mmap(NULL, 11584, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) = 0x410aa000
old_mmap(0x410ac000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 8,
0x1000) = 0x410ac000
close(8)= 0
getdents64(7, /* 0 entries */, 131072) = 0
close(7)= 0
open(/usr/lib/xmms/Effect, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 7
fstat64(7, {st_mode=S_IFDIR|0755, st_size=144, ...}) = 0
fcntl64(7, F_SETFD, FD_CLOEXEC) = 0
getdents64(7, /* 5 entries */, 131072) = 144
stat64(/usr/lib/xmms/Effect/., {st_mode=S_IFDIR|0755, st_size=144, ...}) = 0
stat64(/usr/lib/xmms/Effect/.., {st_mode=S_IFDIR|0755, st_size=176, ...}) =
0
stat64(/usr/lib/xmms/Effect/libvoice.so, {st_mode=S_IFREG|0644,
st_size=5064, ...}) = 0
open(/usr/lib/xmms/Effect/libvoice.so, O_RDONLY) = 8
read(8, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\7\0..., 512) =
512
fstat64(8, {st_mode=S_IFREG|0644, st_size=5064, ...}) = 0
old_mmap(NULL, 8128, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) = 0x410ad000
old_mmap(0x410ae000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 8, 0)
= 0x410ae000
close(8)= 0
stat64(/usr/lib/xmms/Effect/libstereo.so, {st_mode=S_IFREG|0644,
st_size=8620, ...}) = 0
open(/usr/lib/xmms/Effect/libstereo.so, O_RDONLY) = 8
read(8, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\r\0..., 512) =
512
fstat64(8, {st_mode=S_IFREG|0644, st_size=8620, ...}) = 0
old_mmap(NULL, 11692, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) = 0x410af000
old_mmap(0x410b1000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 8,
0x1000) = 0x410b1000
close(8)= 0
stat64(/usr/lib/xmms/Effect/libecho.so, {st_mode=S_IFREG|0644,
st_size=12400, ...}) = 0
open(/usr/lib/xmms/Effect/libecho.so, O_RDONLY) = 8
read(8, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\24\0..., 512) =
512
fstat64(8, {st_mode=S_IFREG|0644, st_size=12400, ...}) = 0
old_mmap(NULL, 15504, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) = 0x410b2000
old_mmap(0x410b5000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 8,
0x2000) = 0x410b5000
close(8)= 0
getdents64(7, /* 0 entries */, 131072) = 0
close(7)= 0
open(/usr/lib/xmms/General, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 7
fstat64(7, {st_mode=S_IFDIR|0755, st_size=144, ...}) = 0
fcntl64(7, F_SETFD, FD_CLOEXEC) = 0
getdents64(7, /* 5 entries */,
Bug#219352: xmms libc crash
On Thu, Nov 13, 2003 at 02:54:40AM +0100, Felix Seeger wrote:
open(/usr/lib/tls/libGL.so.1, O_RDONLY) = 8
read(8, [EMAIL PROTECTED]..., 512) =
512
fstat64(8, {st_mode=S_IFREG|0755, st_size=430820, ...}) = 0
writev(2, [{Inconsistency detected by ld.so:..., 33},
{../sysdeps/generic/dl-tls.c, 27}, {: , 2}, {72, 2}, {: , 2},
{_dl_next_tls_modid, 18}, {: , 2}, {Assertion `, 11}, {result =
_rtld_local._dl_tls_ma..., 41}, {\' failed!\n, 10}], 10Inconsistency
detected by ld.so: ../sysdeps/generic/dl-tls.c: 72: _dl_next_tls_modid:
Assertion `result = _rtld_local._dl_tls_max_dtv_idx' failed!
) = 148
exit_group(127) = ?
Then this bug is almost certainly related to the nvidia-glx drivers.
Either as a libc bug or a TLS problem; it's hard to say without
investigating more but that may let Goto-san reproduce it?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Bug#218657: the latest libc6 + 2.6 kernel problem
Andi Kleen and David Miller believe this bug, or at the least the
symptoms of statfs64(), are caused by a bug in the kernel. Here is the
proposed patch:
--- fs/compat.c.~1~ Wed Nov 12 16:09:49 2003
+++ fs/compat.c Wed Nov 12 16:10:35 2003
@@ -169,7 +169,6 @@
static int put_compat_statfs64(struct compat_statfs64 *ubuf, struct kstatfs
*kbuf)
{
-
if (sizeof ubuf-f_blocks == 4) {
if ((kbuf-f_blocks | kbuf-f_bfree |
kbuf-f_bavail | kbuf-f_files | kbuf-f_ffree)
@@ -192,10 +191,13 @@
return 0;
}
-asmlinkage long compat_statfs64(const char *path, struct compat_statfs64 *buf)
+asmlinkage long compat_statfs64(const char *path, compat_size_t sz, struct
compat_statfs64 *buf)
{
struct nameidata nd;
int error;
+
+ if (sz != sizeof(*buf))
+ return -EINVAL;
error = user_path_walk(path, nd);
if (!error) {
Bug#220517: linux-kernel-headers: I2C support broken, prevents building several packages
Package: linux-kernel-headers Version: 2.5.999-test7-bk-9 Severity: important For example: gcc -DHAVE_CONFIG_H -I. -I../../../gfxdrivers/matrox -I../.. -I../../../include -I../../../src -D_REENTRANT -Wall -O3 -ffast-math -pipe -DFUSION_FAKE -Werror-implicit-function-declaration -c ../../../gfxdrivers/matrox/matrox_maven.c -fPIC -DPIC -o matrox_maven.lo In file included from ../../../gfxdrivers/matrox/matrox_maven.c:32: /usr/include/linux/i2c-dev.h:37: error: field `__user' has incomplete type /usr/include/linux/i2c-dev.h:37: error: parse error before '*' token /usr/include/linux/i2c-dev.h:42: error: field `__user' has incomplete type /usr/include/linux/i2c-dev.h:42: error: parse error before '*' token /usr/include/linux/i2c-dev.h:44: error: parse error before '}' token ../../../gfxdrivers/matrox/matrox_maven.c: In function `maven_write_byte': ../../../gfxdrivers/matrox/matrox_maven.c:63: error: implicit declaration of function `i2c_smbus_write_byte_data' ../../../gfxdrivers/matrox/matrox_maven.c: In function `maven_write_word': ../../../gfxdrivers/matrox/matrox_maven.c:80: error: implicit declaration of function `i2c_smbus_write_word_data' ../../../gfxdrivers/matrox/matrox_maven.c: In function `maven_open': ../../../gfxdrivers/matrox/matrox_maven.c:311: error: `I2C_SLAVE' undeclared (first use in this function) ../../../gfxdrivers/matrox/matrox_maven.c:311: error: (Each undeclared identifier is reported only once ../../../gfxdrivers/matrox/matrox_maven.c:311: error: for each function it appears in.) ../../../gfxdrivers/matrox/matrox_maven.c: In function `maven_init': ../../../gfxdrivers/matrox/matrox_maven.c:450: error: `I2C_SLAVE' undeclared (first use in this function) make[4]: *** [matrox_maven.lo] Error 1 Given how libc6-dev has now become dependant upon linux-kernel-headers (why the hell wasn't libc6-dev designed to accomodate an existing and reliable kernel-headers-2.4.xx to fulfill this dependency? ARGH!), I very much have to consider this an important bug. -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux omena 2.4.22-ben2 #1 ti syyskuun 23. 21:23:03 EEST 2003 ppc Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set to [EMAIL PROTECTED]) -- no debconf information
Bug#220517: linux-kernel-headers: I2C support broken, prevents building several packages
On Thu, Nov 13, 2003 at 05:05:26AM +0200, Martin-Éric Racine wrote: Package: linux-kernel-headers Version: 2.5.999-test7-bk-9 Severity: important For example: gcc -DHAVE_CONFIG_H -I. -I../../../gfxdrivers/matrox -I../.. -I../../../include -I../../../src -D_REENTRANT -Wall -O3 -ffast-math -pipe -DFUSION_FAKE -Werror-implicit-function-declaration -c ../../../gfxdrivers/matrox/matrox_maven.c -fPIC -DPIC -o matrox_maven.lo In file included from ../../../gfxdrivers/matrox/matrox_maven.c:32: /usr/include/linux/i2c-dev.h:37: error: field `__user' has incomplete type Does adding an include of linux/compiler.h at the top of i2c-dev.h fix it? /usr/include/linux/i2c-dev.h:37: error: parse error before '*' token /usr/include/linux/i2c-dev.h:42: error: field `__user' has incomplete type /usr/include/linux/i2c-dev.h:42: error: parse error before '*' token /usr/include/linux/i2c-dev.h:44: error: parse error before '}' token ../../../gfxdrivers/matrox/matrox_maven.c: In function `maven_write_byte': ../../../gfxdrivers/matrox/matrox_maven.c:63: error: implicit declaration of function `i2c_smbus_write_byte_data' ../../../gfxdrivers/matrox/matrox_maven.c: In function `maven_write_word': ../../../gfxdrivers/matrox/matrox_maven.c:80: error: implicit declaration of function `i2c_smbus_write_word_data' ../../../gfxdrivers/matrox/matrox_maven.c: In function `maven_open': ../../../gfxdrivers/matrox/matrox_maven.c:311: error: `I2C_SLAVE' undeclared (first use in this function) ../../../gfxdrivers/matrox/matrox_maven.c:311: error: (Each undeclared identifier is reported only once ../../../gfxdrivers/matrox/matrox_maven.c:311: error: for each function it appears in.) ../../../gfxdrivers/matrox/matrox_maven.c: In function `maven_init': ../../../gfxdrivers/matrox/matrox_maven.c:450: error: `I2C_SLAVE' undeclared (first use in this function) make[4]: *** [matrox_maven.lo] Error 1 Given how libc6-dev has now become dependant upon linux-kernel-headers (why the hell wasn't libc6-dev designed to accomodate an existing and reliable kernel-headers-2.4.xx to fulfill this dependency? ARGH!), I very much have to consider this an important bug. Kindly read any of the hundred explanations of this decision in the -glibc or -devel archives before ranting about it. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#219352: xmms libc crash
On Thursday 13 November 2003 04:12, Daniel Jacobowitz wrote:
On Thu, Nov 13, 2003 at 02:54:40AM +0100, Felix Seeger wrote:
open(/usr/lib/tls/libGL.so.1, O_RDONLY) = 8
read(8, [EMAIL PROTECTED]..., 512)
= 512
fstat64(8, {st_mode=S_IFREG|0755, st_size=430820, ...}) = 0
writev(2, [{Inconsistency detected by ld.so:..., 33},
{../sysdeps/generic/dl-tls.c, 27}, {: , 2}, {72, 2}, {: , 2},
{_dl_next_tls_modid, 18}, {: , 2}, {Assertion `, 11}, {result =
_rtld_local._dl_tls_ma..., 41}, {\' failed!\n, 10}], 10Inconsistency
detected by ld.so: ../sysdeps/generic/dl-tls.c: 72: _dl_next_tls_modid:
Assertion `result = _rtld_local._dl_tls_max_dtv_idx' failed!
) = 148
exit_group(127) = ?
Then this bug is almost certainly related to the nvidia-glx drivers.
Either as a libc bug or a TLS problem; it's hard to say without
investigating more but that may let Goto-san reproduce it?
Yes, if I move libGL.so... to another place I get:
libmikmod.so.2: cannot open shared object file: No such file or directory
/usr/lib/tls/libGLcore.so.1: undefined symbol: __gl_tls_var0
/usr/lib/tls/libGLcore.so.1: undefined symbol: __gl_tls_var0
But xmms starts.
strings /usr/lib/tls/libGLcore.so.1 | grep nvidia
nvidia id: NVIDIA OpenGL Core Shared Library (libGLcore) (ELF TLS) 1.0-4496
Wed Jul 16 19:52:36 PDT 2003
thanks
Felix
Processing of glibc_2.3.2.ds1-10.0.1_arm.changes
glibc_2.3.2.ds1-10.0.1_arm.changes isn't signed with PGP/GnuPG Removing glibc_2.3.2.ds1-10.0.1_arm.changes, but keeping its associated files for now. Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#216921: other problems related to bug 216921
Hello, I upgraded to today's unstable and it seems there are other errors again: In file included from /usr/include/asm/sigcontext.h:4, from /usr/include/bits/sigcontext.h:28, from /usr/include/signal.h:326, from /home/damien/tt/Asterisk/pwlib/include/ptlib/unix/ptlib/pmachdep.h:167, from /home/damien/tt/Asterisk/pwlib/include/ptlib/unix/ptlib/contain.h:61, from /home/damien/tt/Asterisk/pwlib/include/ptlib/../ptlib.h:146, from common.h:45, from ldap_window.h:43, from callbacks.cpp:42: /usr/include/linux/compiler.h:17: warning: `__attribute_used__' redefined /usr/include/sys/cdefs.h:195: warning: this is the location of the previous definition In file included from /home/damien/tt/Asterisk/pwlib/include/ptlib/../ptlib.h:169, -- _ Damien Sandras (o- //\ It-Optics s.a. v_/_GnomeMeeting: http://www.gnomemeeting.org/ FOSDEM 2004: http://www.fosdem.org H.323 phone: callto:ils.seconix.com/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#216921: other problems related to bug 216921
Apparently it only appears with g++-2.95.4. g++ 3.3 doesn't give that kind of problem. -- _ Damien Sandras (o- //\ It-Optics s.a. v_/_GnomeMeeting: http://www.gnomemeeting.org/ FOSDEM 2004: http://www.fosdem.org H.323 phone: callto:ils.seconix.com/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#203303: This is not grave
Package: libc6-dev Version: 2.3.2.ds1-10 Severity: normal Followup-For: Bug #203303 It looks like the problem is that these various KDE programs are using -ansi, and -ansi implies -fno-asm. This in itself wouldn't be the problem, but: The -ansi option does not cause non-ISO programs to be rejected gratuitously. For that, -pedantic is required in addition to -ansi. - taken from the FM. It appears that at least my program is building fine on many arches that it previously failed on once I removed the -ansi and -pedantic lines. I have not yet tested kdemultimedia. So, I would say that while it would be great if the linux-kernel-headers package could provide ansi compliant headers, I realize that that will not be trivial to implement, and as there appears to be a functional workaround, I suggest downgrading to important or normal. If you agree, please do so. I will cc: Chris on this as well, so he knows that there are wokrarounds at least. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux busybox 2.4.22-1-686 #6 Sat Oct 4 14:09:08 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to en_US.ISO-8859-1) Versions of packages libc6-dev depends on: ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries an ii linux-kernel-headers 2.5.999-test7-bk-9 Linux Kernel Headers for developme -- no debconf information -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#219943: Additional useful information regarding libc6 (2.3.2.ds1-*) and Nvidia GL[X] libs
Duck, This is an installer problem, not a libc6 problem. To verify, download the x86 Nvidia 1.0-4496 installer from Nvidia's website, edit the top- level Makefile's install: target (remove kernel_module_install from the end of the line), then run make install. Verify that /usr/lib/tls/libGL* exist. I'm also appending MD5sums of the relevant binaries from 1.0-4496. 060b4cd6db19e26e995f523c3fa8bbdf /usr/lib/tls/libGL.so.1.0.4496 35c680fcbb0ce38bc246cacbb38eabb1 /usr/lib/tls/libGLcore.so.1.0.4496 ac85f1f9908f94282ed14a526fb319e1 /usr/X11R6/lib/modules/extensions/libglx.so.1.0.4496 That is the procedure I followed during the libc6 upgrade. Hope this helps. -D -- Daniel T. Chen [EMAIL PROTECTED] GPG key: www.sh.nu/~crimsun/pubkey.gpg.asc pgp0.pgp Description: PGP signature
Bug#219352: xmms libc crash
At Tue, 11 Nov 2003 20:23:58 +0100, Felix Seeger wrote: On Tuesday 11 November 2003 18:19, Juergen Kreileder wrote: Jeff Bailey [EMAIL PROTECTED] writes: On Wed, Nov 12, 2003 at 12:49:38AM +0900, GOTO Masanori wrote: I also tested on both 2.4 and 2.6 kernel, even with removing ~/.xmms. However I cannot reproduce it... Which CPU do you use? I use an AMD Athlon XP 2500+ on an Asus nforce2 board with nvidia drivers. I also cannot reproduce 2.4 kernel on k7 using Debian's package, and Pentium 2 Xeon, using Debian's 2.6.0-test9 kernel package. The original bug report says Unless libmikmod2 is installed [...]. (xmms recommends libmikmod2.) If I move /usr/lib/libmikmod.so.2* out of the way I can reproduce this problem with 2.6.0-test9-mm2: Yes, if I install libmikmod2 xmms starts up normally. This problem is occured under: - kernel 2.6.0-test9 - glibc 2.3.2.ds1-9 - CPU is not related? - xmms 1.2.8-2 - libmikmod 3.1.10-5 - you might not install libc6-i686 - we use unstable sid. I use such environment, but I cannot reproduce this problem... Please check your environment settings, and if you can, please track with gdb and strace. This bug may be downgraded to important... Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#219352: xmms libc crash
On Thursday 13 November 2003 02:11, GOTO Masanori wrote:
At Tue, 11 Nov 2003 20:23:58 +0100,
Felix Seeger wrote:
On Tuesday 11 November 2003 18:19, Juergen Kreileder wrote:
Jeff Bailey [EMAIL PROTECTED] writes:
On Wed, Nov 12, 2003 at 12:49:38AM +0900, GOTO Masanori wrote:
I also tested on both 2.4 and 2.6 kernel, even with removing
~/.xmms. However I cannot reproduce it... Which CPU do you use?
I use an AMD Athlon XP 2500+ on an Asus nforce2 board with nvidia
drivers.
I also cannot reproduce 2.4 kernel on k7 using Debian's package, and
Pentium 2 Xeon, using Debian's 2.6.0-test9 kernel package.
The original bug report says Unless libmikmod2 is installed [...].
(xmms recommends libmikmod2.)
If I move /usr/lib/libmikmod.so.2* out of the way I can reproduce
this problem with 2.6.0-test9-mm2:
Yes, if I install libmikmod2 xmms starts up normally.
This problem is occured under:
- kernel 2.6.0-test9
- glibc 2.3.2.ds1-9
2.3.2.ds1-10, but I think it also happend with -9
- CPU is not related?
Don't know
- xmms 1.2.8-2
- libmikmod 3.1.10-5
If not installed
- you might not install libc6-i686
yes, not installed
- we use unstable sid.
yes
I use such environment, but I cannot reproduce this problem... Please
check your environment settings, and if you can, please track with gdb
and strace. This bug may be downgraded to important...
I remove libmikmod2 and run xmms with gdb, but when I type bt, there isn't
one. Here is the strace output from the libmikmod warning on:
write(2, libmikmod.so.2: cannot open shar..., 74libmikmod.so.2: cannot open
shared object file: No such file or directory
) = 74
stat64(/usr/lib/xmms/Input/libcdaudio.so, {st_mode=S_IFREG|0644,
st_size=55440, ...}) = 0
open(/usr/lib/xmms/Input/libcdaudio.so, O_RDONLY) = 8
read(8, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 2\0\000..., 512) =
512
fstat64(8, {st_mode=S_IFREG|0644, st_size=55440, ...}) = 0
old_mmap(NULL, 56736, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) = 0x4109c000
old_mmap(0x410a9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 8,
0xd000) = 0x410a9000
close(8)= 0
stat64(/usr/lib/xmms/Input/libtonegen.so, {st_mode=S_IFREG|0644,
st_size=8508, ...}) = 0
open(/usr/lib/xmms/Input/libtonegen.so, O_RDONLY) = 8
read(8, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\t\0..., 512) =
512
fstat64(8, {st_mode=S_IFREG|0644, st_size=8508, ...}) = 0
old_mmap(NULL, 11584, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) = 0x410aa000
old_mmap(0x410ac000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 8,
0x1000) = 0x410ac000
close(8)= 0
getdents64(7, /* 0 entries */, 131072) = 0
close(7)= 0
open(/usr/lib/xmms/Effect, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 7
fstat64(7, {st_mode=S_IFDIR|0755, st_size=144, ...}) = 0
fcntl64(7, F_SETFD, FD_CLOEXEC) = 0
getdents64(7, /* 5 entries */, 131072) = 144
stat64(/usr/lib/xmms/Effect/., {st_mode=S_IFDIR|0755, st_size=144, ...}) = 0
stat64(/usr/lib/xmms/Effect/.., {st_mode=S_IFDIR|0755, st_size=176, ...}) =
0
stat64(/usr/lib/xmms/Effect/libvoice.so, {st_mode=S_IFREG|0644,
st_size=5064, ...}) = 0
open(/usr/lib/xmms/Effect/libvoice.so, O_RDONLY) = 8
read(8, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\7\0..., 512) =
512
fstat64(8, {st_mode=S_IFREG|0644, st_size=5064, ...}) = 0
old_mmap(NULL, 8128, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) = 0x410ad000
old_mmap(0x410ae000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 8, 0)
= 0x410ae000
close(8)= 0
stat64(/usr/lib/xmms/Effect/libstereo.so, {st_mode=S_IFREG|0644,
st_size=8620, ...}) = 0
open(/usr/lib/xmms/Effect/libstereo.so, O_RDONLY) = 8
read(8, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\r\0..., 512) =
512
fstat64(8, {st_mode=S_IFREG|0644, st_size=8620, ...}) = 0
old_mmap(NULL, 11692, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) = 0x410af000
old_mmap(0x410b1000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 8,
0x1000) = 0x410b1000
close(8)= 0
stat64(/usr/lib/xmms/Effect/libecho.so, {st_mode=S_IFREG|0644,
st_size=12400, ...}) = 0
open(/usr/lib/xmms/Effect/libecho.so, O_RDONLY) = 8
read(8, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\24\0..., 512) =
512
fstat64(8, {st_mode=S_IFREG|0644, st_size=12400, ...}) = 0
old_mmap(NULL, 15504, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) = 0x410b2000
old_mmap(0x410b5000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 8,
0x2000) = 0x410b5000
close(8)= 0
getdents64(7, /* 0 entries */, 131072) = 0
close(7)= 0
open(/usr/lib/xmms/General, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 7
fstat64(7, {st_mode=S_IFDIR|0755, st_size=144, ...}) = 0
fcntl64(7, F_SETFD, FD_CLOEXEC) = 0
getdents64(7, /* 5 entries */,
Bug#219352: xmms libc crash
On Thu, Nov 13, 2003 at 02:54:40AM +0100, Felix Seeger wrote:
open(/usr/lib/tls/libGL.so.1, O_RDONLY) = 8
read(8, [EMAIL PROTECTED]..., 512) =
512
fstat64(8, {st_mode=S_IFREG|0755, st_size=430820, ...}) = 0
writev(2, [{Inconsistency detected by ld.so:..., 33},
{../sysdeps/generic/dl-tls.c, 27}, {: , 2}, {72, 2}, {: , 2},
{_dl_next_tls_modid, 18}, {: , 2}, {Assertion `, 11}, {result =
_rtld_local._dl_tls_ma..., 41}, {\' failed!\n, 10}], 10Inconsistency
detected by ld.so: ../sysdeps/generic/dl-tls.c: 72: _dl_next_tls_modid:
Assertion `result = _rtld_local._dl_tls_max_dtv_idx' failed!
) = 148
exit_group(127) = ?
Then this bug is almost certainly related to the nvidia-glx drivers.
Either as a libc bug or a TLS problem; it's hard to say without
investigating more but that may let Goto-san reproduce it?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#218657: the latest libc6 + 2.6 kernel problem
Andi Kleen and David Miller believe this bug, or at the least the
symptoms of statfs64(), are caused by a bug in the kernel. Here is the
proposed patch:
--- fs/compat.c.~1~ Wed Nov 12 16:09:49 2003
+++ fs/compat.c Wed Nov 12 16:10:35 2003
@@ -169,7 +169,6 @@
static int put_compat_statfs64(struct compat_statfs64 *ubuf, struct kstatfs *kbuf)
{
-
if (sizeof ubuf-f_blocks == 4) {
if ((kbuf-f_blocks | kbuf-f_bfree |
kbuf-f_bavail | kbuf-f_files | kbuf-f_ffree)
@@ -192,10 +191,13 @@
return 0;
}
-asmlinkage long compat_statfs64(const char *path, struct compat_statfs64 *buf)
+asmlinkage long compat_statfs64(const char *path, compat_size_t sz, struct
compat_statfs64 *buf)
{
struct nameidata nd;
int error;
+
+ if (sz != sizeof(*buf))
+ return -EINVAL;
error = user_path_walk(path, nd);
if (!error) {
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#220517: linux-kernel-headers: I2C support broken, prevents building several packages
Package: linux-kernel-headers Version: 2.5.999-test7-bk-9 Severity: important For example: gcc -DHAVE_CONFIG_H -I. -I../../../gfxdrivers/matrox -I../.. -I../../../include -I../../../src -D_REENTRANT -Wall -O3 -ffast-math -pipe -DFUSION_FAKE -Werror-implicit-function-declaration -c ../../../gfxdrivers/matrox/matrox_maven.c -fPIC -DPIC -o matrox_maven.lo In file included from ../../../gfxdrivers/matrox/matrox_maven.c:32: /usr/include/linux/i2c-dev.h:37: error: field `__user' has incomplete type /usr/include/linux/i2c-dev.h:37: error: parse error before '*' token /usr/include/linux/i2c-dev.h:42: error: field `__user' has incomplete type /usr/include/linux/i2c-dev.h:42: error: parse error before '*' token /usr/include/linux/i2c-dev.h:44: error: parse error before '}' token ../../../gfxdrivers/matrox/matrox_maven.c: In function `maven_write_byte': ../../../gfxdrivers/matrox/matrox_maven.c:63: error: implicit declaration of function `i2c_smbus_write_byte_data' ../../../gfxdrivers/matrox/matrox_maven.c: In function `maven_write_word': ../../../gfxdrivers/matrox/matrox_maven.c:80: error: implicit declaration of function `i2c_smbus_write_word_data' ../../../gfxdrivers/matrox/matrox_maven.c: In function `maven_open': ../../../gfxdrivers/matrox/matrox_maven.c:311: error: `I2C_SLAVE' undeclared (first use in this function) ../../../gfxdrivers/matrox/matrox_maven.c:311: error: (Each undeclared identifier is reported only once ../../../gfxdrivers/matrox/matrox_maven.c:311: error: for each function it appears in.) ../../../gfxdrivers/matrox/matrox_maven.c: In function `maven_init': ../../../gfxdrivers/matrox/matrox_maven.c:450: error: `I2C_SLAVE' undeclared (first use in this function) make[4]: *** [matrox_maven.lo] Error 1 Given how libc6-dev has now become dependant upon linux-kernel-headers (why the hell wasn't libc6-dev designed to accomodate an existing and reliable kernel-headers-2.4.xx to fulfill this dependency? ARGH!), I very much have to consider this an important bug. -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux omena 2.4.22-ben2 #1 ti syyskuun 23. 21:23:03 EEST 2003 ppc Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set to [EMAIL PROTECTED]) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#219352: xmms libc crash
On Thursday 13 November 2003 04:12, Daniel Jacobowitz wrote:
On Thu, Nov 13, 2003 at 02:54:40AM +0100, Felix Seeger wrote:
open(/usr/lib/tls/libGL.so.1, O_RDONLY) = 8
read(8, [EMAIL PROTECTED]..., 512)
= 512
fstat64(8, {st_mode=S_IFREG|0755, st_size=430820, ...}) = 0
writev(2, [{Inconsistency detected by ld.so:..., 33},
{../sysdeps/generic/dl-tls.c, 27}, {: , 2}, {72, 2}, {: , 2},
{_dl_next_tls_modid, 18}, {: , 2}, {Assertion `, 11}, {result =
_rtld_local._dl_tls_ma..., 41}, {\' failed!\n, 10}], 10Inconsistency
detected by ld.so: ../sysdeps/generic/dl-tls.c: 72: _dl_next_tls_modid:
Assertion `result = _rtld_local._dl_tls_max_dtv_idx' failed!
) = 148
exit_group(127) = ?
Then this bug is almost certainly related to the nvidia-glx drivers.
Either as a libc bug or a TLS problem; it's hard to say without
investigating more but that may let Goto-san reproduce it?
Yes, if I move libGL.so... to another place I get:
libmikmod.so.2: cannot open shared object file: No such file or directory
/usr/lib/tls/libGLcore.so.1: undefined symbol: __gl_tls_var0
/usr/lib/tls/libGLcore.so.1: undefined symbol: __gl_tls_var0
But xmms starts.
strings /usr/lib/tls/libGLcore.so.1 | grep nvidia
nvidia id: NVIDIA OpenGL Core Shared Library (libGLcore) (ELF TLS) 1.0-4496
Wed Jul 16 19:52:36 PDT 2003
thanks
Felix
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
