Problems with Schrodinger MacroModel and Mathworks Matlab - libc6

Bug #15502 reported by prg3
6
Affects Status Importance Assigned to Milestone
glibc (Debian)
Fix Released
Unknown
glibc (Ubuntu)
Fix Released
Medium
Jeff Bailey

Bug Description

I get this error from Schrodinger MacroModel:

Inconsistency detected by ld.so: rtld.c: 1259: dl_main: Assertion
`_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed!
WARNING : MMPROJ ERROR(-4): mmproj_incorporate_jobfe()():
        Failed to open structure file '/tmp/mmodtmp-out.mae' for reading. The
job may have failed

I get this from Matlab:

Inconsistency detected by ld.so: rtld.c: 1259: dl_main: Assertion
`_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed!

and, "/lib/libc.so.6" gives:
Inconsistency detected by ld.so: rtld.c: 1259: dl_main: Assertion
`_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed!

I am running Hoary, new install. running libc -20ubuntu13.

This bug is similar to budID 26, but seing as I am running a version above the
fixed version and still getting the same problem, this might need to be looked
at again.
https://bugzilla.ubuntu.com/show_bug.cgi?id=26

Thanks

Revision history for this message
In , GOTO Masanori (gotom-debian) wrote : Re: Bug#274852: /lib/libc.so.6 is not executable

merge 210840 274852 207872
thanks

At Mon, 04 Oct 2004 13:25:54 +0200,
Francesco Paolo Lovergine wrote:
> On other distros (e.g. RH) /lib/libc.so.6 is executable and returns
> mainly libc version.
>
> This is used in some scripts to check compatibilities and so breaks things.
> For instance, it breaks Mathworks' Matlab internal scripts which uses
> something like
>
> ver=`/lib/libc.so.6 | head -1 | sed -e "s/^[^0-9]*//" -e "s/[ ,].*$//"`
>
> to extract libc release.
>
> If +x is added to libc.so.6, it fails as follows:
>
> Inconsistency detected by ld.so: rtld.c: 1259: dl_main: \
> Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed!

It was already reported. This will be fixed in the next glibc update.

Regards,
-- gotom

Revision history for this message
In , GOTO Masanori (gotom-debian) wrote : Re: Bug#276384: Inconsistency detected by ld.so: rtld.c

severity 276384 normal
merge 276384 207872 210840 274852
thanks

At Wed, 13 Oct 2004 19:51:48 +0200,
Martin Lueer wrote:
> I'm unable to run a few programs couse of this error-msg:
> Inconsistency detected by ld.so: rtld.c: 1259: dl_main: Assertion
> `_rtld_local._dl_rtld_map.l_prev->l_next ==
> _rtld_local._dl_rtld_map.l_next' failed!
>
> You are able to reproduce this problem by:
> chmod u+x /lib/libc.so.6
> /lib/libc.so.6
>
> I saw an earlier bugreport dealing with the same error but with
> earlier versions.
>
> Here is a workaround and a more detailed description of this problem:
> http://sources.redhat.com/ml/libc-alpha/2003-09/msg00261.html.
>
> I'm using a self compiled Kernel 2.6.8.1 and sarge

Please check BTS before submitting report...

Regards,
-- gotom

Revision history for this message
In , David Martínez Moreno (ender) wrote : Bug #274852: But in which upstream version?

        Good morning. I launched xmms several times from a Run... window in
KDE before noticing that something was going wrong:

ender@jane:~$ xmms
libmikmod.so.2: cannot open shared object file: No such file or directory
Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 72: _dl_next_tls_modid: Assertion `result <= _rtld_local._dl_tls_max_dtv_idx' failed!

        GOTO, in your last message to this bug you state that the next
libc6 release you will include a fix for this, but I have the
latest (-20) from Dec and I have this problem.

        My kernel is 2.6.7 vanilla, nvidia drivers, libc6-i686 libraries,
and Debian testing.

        I reinstalled xmms, but that didn't fix the problem.

        Also, the bug says that is fixed upstream. If, as Daniel says in
#207872, the patch was rejected upstream, you should remove the tag.

        Do not hesitate to ask for further information.

        Best regards,

                Ender.
--
Network engineer
Debian Developer

Revision history for this message
In , GOTO Masanori (gotom-debian) wrote : Re: Bug#274852: Bug #274852: But in which upstream version?

At Wed, 16 Feb 2005 12:36:23 +0100,
David Mart�z Moreno wrote:
> ender@jane:~$ xmms
> libmikmod.so.2: cannot open shared object file: No such file or directory
> Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 72: _dl_next_tls_modid: Assertion `result <= _rtld_local._dl_tls_max_dtv_idx' failed!
>
> GOTO, in your last message to this bug you state that the next
> libc6 release you will include a fix for this, but I have the
> latest (-20) from Dec and I have this problem.

I'm sorry that my previous statement was in accurate - "the next glibc
update" means we use the new upstream version - ex: glibc-2.3.4. So I
tagged it as "fixed-upstream".

> Also, the bug says that is fixed upstream. If, as Daniel says in
> #207872, the patch was rejected upstream, you should remove the tag.

I guess upstream did the another way to fix this issue. Daniel, did
you know about it more?

Regards,
-- gotom

Revision history for this message
In , Daniel Jacobowitz (drow) wrote :

On Mon, Feb 28, 2005 at 10:23:14AM +0900, GOTO Masanori wrote:
> At Wed, 16 Feb 2005 12:36:23 +0100,
> David Mart?nez Moreno wrote:
> > ender@jane:~$ xmms
> > libmikmod.so.2: cannot open shared object file: No such file or directory
> > Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 72: _dl_next_tls_modid: Assertion `result <= _rtld_local._dl_tls_max_dtv_idx' failed!
> >
> > GOTO, in your last message to this bug you state that the next
> > libc6 release you will include a fix for this, but I have the
> > latest (-20) from Dec and I have this problem.
>
> I'm sorry that my previous statement was in accurate - "the next glibc
> update" means we use the new upstream version - ex: glibc-2.3.4. So I
> tagged it as "fixed-upstream".
>
> > Also, the bug says that is fixed upstream. If, as Daniel says in
> > #207872, the patch was rejected upstream, you should remove the tag.
>
> I guess upstream did the another way to fix this issue. Daniel, did
> you know about it more?

No, sorry - I don't know if or how it was fixed.

--
Daniel Jacobowitz
CodeSourcery, LLC

Revision history for this message
In , David Martínez Moreno (ender) wrote :

El Lunes, 28 de Febrero de 2005 02:23, GOTO Masanori escribió:
> At Wed, 16 Feb 2005 12:36:23 +0100,
>
> David Mart�z Moreno wrote:
> > ender@jane:~$ xmms
> > libmikmod.so.2: cannot open shared object file: No such file or directory
> > Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 72:
> > _dl_next_tls_modid: Assertion `result <= _rtld_local._dl_tls_max_dtv_idx'
> > failed!
> >
> > GOTO, in your last message to this bug you state that the next
> > libc6 release you will include a fix for this, but I have the
> > latest (-20) from Dec and I have this problem.

        Hello, GOTO.

> I'm sorry that my previous statement was in accurate - "the next glibc
> update" means we use the new upstream version - ex: glibc-2.3.4. So I
> tagged it as "fixed-upstream".

        Oh, *that* glibc update. :-)

> > Also, the bug says that is fixed upstream. If, as Daniel says in
> > #207872, the patch was rejected upstream, you should remove the tag.
>
> I guess upstream did the another way to fix this issue. Daniel, did
> you know about it more?

        Yes, please. Because if upstream fixed this, we could backport the
changes to current glibc, because I do not think that this problem of not
being able to run certain programs is very desirable for sarge. I will wait
for Daniel's answer.

        Thank you very much for your reply- Best regards,

                Ender.
--
Network engineer
Debian Developer

Revision history for this message
prg3 (paul-greidanus) wrote :

I get this error from Schrodinger MacroModel:

Inconsistency detected by ld.so: rtld.c: 1259: dl_main: Assertion
`_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed!
WARNING : MMPROJ ERROR(-4): mmproj_incorporate_jobfe()():
        Failed to open structure file '/tmp/mmodtmp-out.mae' for reading. The
job may have failed

I get this from Matlab:

Inconsistency detected by ld.so: rtld.c: 1259: dl_main: Assertion
`_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed!

and, "/lib/libc.so.6" gives:
Inconsistency detected by ld.so: rtld.c: 1259: dl_main: Assertion
`_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed!

I am running Hoary, new install. running libc -20ubuntu13.

This bug is similar to budID 26, but seing as I am running a version above the
fixed version and still getting the same problem, this might need to be looked
at again.
https://bugzilla.ubuntu.com/show_bug.cgi?id=26

Thanks

Revision history for this message
Jeff Bailey (jbailey) wrote :

This looks like Debian bug report 274852. If that's what it is, then it's fixed
in the upload of glibc to breezy.

I don't recommend you move to breezy right now, since we've just updated the
toolchain and are in the process of merging new revisions of packages. When it
settles down, can you give it a try? It might also be an option to try it in a
chroot or on a machine that you don't mind running possibly unstable and
experimental packages.

Revision history for this message
prg3 (paul-greidanus) wrote :

Breezy seems to have fixed the problem. The machine itself is
testing/experimental, so I just upgraded the whole thing, and everything looks fine.

Next, get users to hammer on it.

Revision history for this message
Jeff Bailey (jbailey) wrote :

Excellent. I've marked that it's the same bug then and will close this for now.
 If you have any further problems, please feel free to reopen this.

Tks,
Jeff Bailey

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <E1CEQyY-0000w1-Nm@klecker>
Date: Mon, 04 Oct 2004 13:25:54 +0200
From: Francesco Paolo Lovergine <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: /lib/libc.so.6 is not executable

Package: libc6
Version: 2.3.2.ds1-16
Severity: normal

On other distros (e.g. RH) /lib/libc.so.6 is executable and returns
mainly libc version.

This is used in some scripts to check compatibilities and so breaks things.
For instance, it breaks Mathworks' Matlab internal scripts which uses
something like

ver=`/lib/libc.so.6 | head -1 | sed -e "s/^[^0-9]*//" -e "s/[ ,].*$//"`

to extract libc release.

If +x is added to libc.so.6, it fails as follows:

Inconsistency detected by ld.so: rtld.c: 1259: dl_main: \
Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed!

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-686
Locale: LANG=it_IT@euro, LC_CTYPE=it_IT@euro

Versions of packages libc6 depends on:
ii libdb1-compat 2.1.3-7 The Berkeley database routines [gl

-- no debconf information

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Tue, 05 Oct 2004 02:03:17 +0900
From: GOTO Masanori <email address hidden>
To: Francesco Paolo Lovergine <email address hidden>,
 <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#274852: /lib/libc.so.6 is not executable

merge 210840 274852 207872
thanks

At Mon, 04 Oct 2004 13:25:54 +0200,
Francesco Paolo Lovergine wrote:
> On other distros (e.g. RH) /lib/libc.so.6 is executable and returns
> mainly libc version.
>
> This is used in some scripts to check compatibilities and so breaks things.
> For instance, it breaks Mathworks' Matlab internal scripts which uses
> something like
>
> ver=`/lib/libc.so.6 | head -1 | sed -e "s/^[^0-9]*//" -e "s/[ ,].*$//"`
>
> to extract libc release.
>
> If +x is added to libc.so.6, it fails as follows:
>
> Inconsistency detected by ld.so: rtld.c: 1259: dl_main: \
> Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed!

It was already reported. This will be fixed in the next glibc update.

Regards,
-- gotom

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Thu, 14 Oct 2004 09:07:50 +0900
From: GOTO Masanori <email address hidden>
To: Martin Lueer <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Re: Bug#276384: Inconsistency detected by ld.so: rtld.c

severity 276384 normal
merge 276384 207872 210840 274852
thanks

At Wed, 13 Oct 2004 19:51:48 +0200,
Martin Lueer wrote:
> I'm unable to run a few programs couse of this error-msg:
> Inconsistency detected by ld.so: rtld.c: 1259: dl_main: Assertion
> `_rtld_local._dl_rtld_map.l_prev->l_next ==
> _rtld_local._dl_rtld_map.l_next' failed!
>
> You are able to reproduce this problem by:
> chmod u+x /lib/libc.so.6
> /lib/libc.so.6
>
> I saw an earlier bugreport dealing with the same error but with
> earlier versions.
>
> Here is a workaround and a more detailed description of this problem:
> http://sources.redhat.com/ml/libc-alpha/2003-09/msg00261.html.
>
> I'm using a self compiled Kernel 2.6.8.1 and sarge

Please check BTS before submitting report...

Regards,
-- gotom

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <email address hidden>
Date: Wed, 16 Feb 2005 12:36:23 +0100
From: David =?iso-8859-1?q?Mart=EDnez_Moreno?= <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: Bug #274852: But in which upstream version?

--nextPart1706251.ANYrT5klU2
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

        Good morning. I launched xmms several times from a Run... window in
KDE before noticing that something was going wrong:

ender@jane:~$ xmms
libmikmod.so.2: cannot open shared object file: No such file or directory
Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 72: _dl_next_=
tls_modid: Assertion `result <=3D _rtld_local._dl_tls_max_dtv_idx' failed!

        GOTO, in your last message to this bug you state that the next
libc6 release you will include a fix for this, but I have the
latest (-20) from Dec and I have this problem.

        My kernel is 2.6.7 vanilla, nvidia drivers, libc6-i686 libraries,
and Debian testing.

        I reinstalled xmms, but that didn't fix the problem.

        Also, the bug says that is fixed upstream. If, as Daniel says in
#207872, the patch was rejected upstream, you should remove the tag.

        Do not hesitate to ask for further information.

        Best regards,

                Ender.
=2D-=20
Network engineer
Debian Developer

--nextPart1706251.ANYrT5klU2
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBCEzBDWs/EhA1iABsRAqWsAKCoqeLBmQsh/xOzrNFg+btwnArLiQCgo++R
uuryrD0/bdLACLT5UiJjjoE=
=QYoX
-----END PGP SIGNATURE-----

--nextPart1706251.ANYrT5klU2--

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Mon, 28 Feb 2005 10:23:14 +0900
From: GOTO Masanori <email address hidden>
To: David =?ISO-8859-1?Q?Mart=EDnez?= Moreno <email address hidden>,
 <email address hidden>
Subject: Re: Bug#274852: Bug #274852: But in which upstream version?

At Wed, 16 Feb 2005 12:36:23 +0100,
David Mart=EDnez Moreno wrote:
> ender@jane:~$ xmms
> libmikmod.so.2: cannot open shared object file: No such file or directory
> Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 72: _dl_nex=
t_tls_modid: Assertion `result <=3D _rtld_local._dl_tls_max_dtv_idx' failed!
>=20
> GOTO, in your last message to this bug you state that the next
> libc6 release you will include a fix for this, but I have the
> latest (-20) from Dec and I have this problem.

I'm sorry that my previous statement was in accurate - "the next glibc
update" means we use the new upstream version - ex: glibc-2.3.4. So I
tagged it as "fixed-upstream".

> Also, the bug says that is fixed upstream. If, as Daniel says in
> #207872, the patch was rejected upstream, you should remove the tag.

I guess upstream did the another way to fix this issue. Daniel, did
you know about it more?

Regards,
-- gotom

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Sun, 27 Feb 2005 20:40:35 -0500
From: Daniel Jacobowitz <email address hidden>
To: GOTO Masanori <email address hidden>, <email address hidden>
Subject: Re: Bug#274852: Bug #274852: But in which upstream version?

On Mon, Feb 28, 2005 at 10:23:14AM +0900, GOTO Masanori wrote:
> At Wed, 16 Feb 2005 12:36:23 +0100,
> David Mart?nez Moreno wrote:
> > ender@jane:~$ xmms
> > libmikmod.so.2: cannot open shared object file: No such file or directory
> > Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 72: _dl_next_tls_modid: Assertion `result <= _rtld_local._dl_tls_max_dtv_idx' failed!
> >
> > GOTO, in your last message to this bug you state that the next
> > libc6 release you will include a fix for this, but I have the
> > latest (-20) from Dec and I have this problem.
>
> I'm sorry that my previous statement was in accurate - "the next glibc
> update" means we use the new upstream version - ex: glibc-2.3.4. So I
> tagged it as "fixed-upstream".
>
> > Also, the bug says that is fixed upstream. If, as Daniel says in
> > #207872, the patch was rejected upstream, you should remove the tag.
>
> I guess upstream did the another way to fix this issue. Daniel, did
> you know about it more?

No, sorry - I don't know if or how it was fixed.

--
Daniel Jacobowitz
CodeSourcery, LLC

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <email address hidden>
Date: Mon, 28 Feb 2005 02:50:11 +0100
From: David =?utf-8?q?Mart=C3=ADnez_Moreno?= <email address hidden>
To: GOTO Masanori <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#274852: Bug #274852: But in which upstream version?

--nextPart1113806.OSykVj449R
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

El Lunes, 28 de Febrero de 2005 02:23, GOTO Masanori escribi=C3=B3:
> At Wed, 16 Feb 2005 12:36:23 +0100,
>
> David Mart=EDnez Moreno wrote:
> > ender@jane:~$ xmms
> > libmikmod.so.2: cannot open shared object file: No such file or directo=
ry
> > Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 72:
> > _dl_next_tls_modid: Assertion `result <=3D _rtld_local._dl_tls_max_dtv_=
idx'
> > failed!
> >
> > GOTO, in your last message to this bug you state that the next
> > libc6 release you will include a fix for this, but I have the
> > latest (-20) from Dec and I have this problem.

        Hello, GOTO.

> I'm sorry that my previous statement was in accurate - "the next glibc
> update" means we use the new upstream version - ex: glibc-2.3.4. So I
> tagged it as "fixed-upstream".

        Oh, *that* glibc update. :-)

> > Also, the bug says that is fixed upstream. If, as Daniel says in
> > #207872, the patch was rejected upstream, you should remove the tag.
>
> I guess upstream did the another way to fix this issue. Daniel, did
> you know about it more?

        Yes, please. Because if upstream fixed this, we could backport the=
=20
changes to current glibc, because I do not think that this problem of not=20
being able to run certain programs is very desirable for sarge. I will wait=
=20
for Daniel's answer.

        Thank you very much for your reply- Best regards,

                Ender.
=2D-=20
Network engineer
Debian Developer

--nextPart1113806.OSykVj449R
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBCInjaWs/EhA1iABsRAthDAKCWJhHVnkzVwEnPFsR4oMGGbGs3hgCg30Am
cDA48s5W+1lowIf0LuwLNLA=
=Smgv
-----END PGP SIGNATURE-----

--nextPart1113806.OSykVj449R--

Revision history for this message
In , Daniel Jacobowitz (drow) wrote : Fixed

This bug is now fixed in unstable, and hopefully will be fixed in sarge.

--
Daniel Jacobowitz
CodeSourcery, LLC

Changed in glibc:
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.