On Sat, Sep 25, 2004 at 01:55:07PM +0200, Eduard Bloch wrote:
> #include <hallo.h>
> * Pierre Machard [Sat, Sep 25 2004, 11:02:41AM]:
>=20
> > > Why did you set the severity back if you did not understand the issue?
> > > The problem here is not a plugin that breaks because of some missing
> > > extra library (which would be okay).=20
> > >=20
> > > > The fact that libmikmod2 is not installed does not prevent xmms to =
work.
> > >=20
> > > Wrong. That is the core of the problem. xmms application does not sta=
rt
> > > at all. I tried to get a backtrace now, but gdb does not produce any
> > > data, maybe it is confused with its thread model. No idea.
> > > However, xmms starts with LD_ASSUME_KERNEL=3D2.4.1 and this problem m=
ay be
> > > somehow related to TLS.
> >=20
> > On my environment (sarge) I have not this problem. I am running a
> > 2.6.7-1-k7 kernel, but when I was running a 2.4.x I had not this
> > problem. Are you running a Debian kernel or are you running a home made
> > kernel ?
>=20
> A-Ha. I think, something reported by several people cannot be just
> random irreproducible problem. In fact, you need following conditions to
> reproduce this bug:
>=20
> - run a 2.6.x kernel (as stated in other bug reports!)
> - have a libc with NTPL/TLS support
> - install the binary nvidia drivers (and make sure it setups its TLS
> libraries)
>
> Then, for some reason, XMMS does this (not) funny thing right after
> libGL.so.1 has been loaded.
The problem is really nvidia drivers. I tryed to forward a similar bug in
the past to the glibc maintainers but It fails. I hope it will work this
time.
Dear glibc maintainers I do not know if the severity is very well
setted, however I would really like to know why nvidia and the behaviour=20
that Eduard described break xmms.
If you prefer, you can duplicate the bug repport and reassign it to
xmms and/or nvidia.
Message-ID: <email address hidden>
Date: Sat, 25 Sep 2004 18:35:42 +0200
From: Pierre Machard <email address hidden>
To: GNU Libc Maintainers <email address hidden>
Cc: <email address hidden>
Subject: [<email address hidden>: Re: xmms/libmikmod2 bug is grave]
--UKNXkkdQCYZ6W5l3 "UBnjLfzoMQYIXC vq" Disposition: inline
Content-Type: multipart/mixed; boundary=
Content-
--UBnjLfzoMQYIXCvq Disposition: inline Transfer- Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Content-
Content-
reassign 261001 glibc
Pierre Machard debian. org
thanks,
--=20
<email address hidden> http://
GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87
--UBnjLfzoMQYIXCvq Disposition: inline
Content-Type: message/rfc822
Content-
Date: Sat, 25 Sep 2004 15:28:55 +0200 "application/ pgp-signature" ; boundary= "K8nIJk4ghYZn60 6h" Disposition: inline 5.6+20040722i
From: Pierre Machard <email address hidden>
To: Eduard Bloch <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: xmms/libmikmod2 bug is grave
Message-ID: <email address hidden>
References: <email address hidden> <email address hidden>
<email address hidden>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol=
Content-
In-Reply-To: <email address hidden>
Organization: debian.org
User-Agent: Mutt/1.
--K8nIJk4ghYZn606h Disposition: inline Transfer- Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Content-
Content-
reassing 261001 glibc
thanks,
Hi Eduard,=20
thanks for your quick reply
On Sat, Sep 25, 2004 at 01:55:07PM +0200, Eduard Bloch wrote: KERNEL= 3D2.4.1 and this problem m=
> #include <hallo.h>
> * Pierre Machard [Sat, Sep 25 2004, 11:02:41AM]:
>=20
> > > Why did you set the severity back if you did not understand the issue?
> > > The problem here is not a plugin that breaks because of some missing
> > > extra library (which would be okay).=20
> > >=20
> > > > The fact that libmikmod2 is not installed does not prevent xmms to =
work.
> > >=20
> > > Wrong. That is the core of the problem. xmms application does not sta=
rt
> > > at all. I tried to get a backtrace now, but gdb does not produce any
> > > data, maybe it is confused with its thread model. No idea.
> > > However, xmms starts with LD_ASSUME_
ay be
> > > somehow related to TLS.
> >=20
> > On my environment (sarge) I have not this problem. I am running a
> > 2.6.7-1-k7 kernel, but when I was running a 2.4.x I had not this
> > problem. Are you running a Debian kernel or are you running a home made
> > kernel ?
>=20
> A-Ha. I think, something reported by several people cannot be just
> random irreproducible problem. In fact, you need following conditions to
> reproduce this bug:
>=20
> - run a 2.6.x kernel (as stated in other bug reports!)
> - have a libc with NTPL/TLS support
> - install the binary nvidia drivers (and make sure it setups its TLS
> libraries)
>
> Then, for some reason, XMMS does this (not) funny thing right after
> libGL.so.1 has been loaded.
The problem is really nvidia drivers. I tryed to forward a similar bug in
the past to the glibc maintainers but It fails. I hope it will work this
time.
Dear glibc maintainers I do not know if the severity is very well
setted, however I would really like to know why nvidia and the behaviour=20
that Eduard described break xmms.
If you prefer, you can duplicate the bug repport and reassign it to
xmms and/or nvidia.
Cheers,
Pierre Machard debian. org
--=20
<email address hidden> http://
GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87
--K8nIJk4ghYZn606h pgp-signature; name="signature .asc" Description: Digital signature Disposition: inline
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
tZiNwb4cRAqcoAJ 49dva8DLhgb4klL iioNN2l3Z4i9QCe O7DJ RnDkuz/ k=
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBVXKXs6A
Z8gLPi5zWmDV4AP
=16Lp
-----END PGP SIGNATURE-----
--K8nIJk4ghYZn6 06h--
--UBnjLfzoMQYIX Cvq--
--UKNXkkdQCYZ6W5l3 pgp-signature; name="signature .asc" Description: Digital signature Disposition: inline
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
tZiNwb4cRAiSbAJ 4ig7fJdGX4MGMQr kONqB4HvLlkPQCg q6C/ jJall4o0=
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBVZ5es6A
zTuU3z25vl23R8G
=E6qv
-----END PGP SIGNATURE-----
--UKNXkkdQCYZ6W 5l3--