[arm] Programmes linked against libacl1 segfault in libacl1 code

[Debian Bug Importer]

Automatically imported from Debian bug report #312936 http://bugs.debian.org/312936

[Steve Langasek (vorlon)]

On Fri, Jun 10, 2005 at 11:36:18PM +0100, Jonathan David Amery wrote:
> I've just upgraded my system from woody to sarge. Among other upgrade
> problems I noticed that programmes like cp, mv and install were occasionally
> segfaulting (and the packages that were invoking them failing to get
> installed), leaving register dumps like this in my logs:

> pc : [<400278ac>] lr : [<4002a348>] Not tainted
> sp : bffff4f4 ip : 40049cf8 fp : bffff780
> r10: 400333bc r9 : bffffa38 r8 : bffff548
> r7 : bffff561 r6 : 00000000 r5 : 0001c324 r4 : bffff50c
> r3 : 00000004 r2 : 00000000 r1 : 00009d6b r0 : bffff508
> Flags: nzCv IRQs on FIQs on Mode USER_32 Segment user
> Control: 1C14917D Table: 1C14917D DAC: 00000015

> Looking at the ldd output for cp makes it quite clear that this is inside
> libacl1:

> libacl.so.1 => /lib/libacl.so.1 (0x40026000)
> libc.so.6 => /lib/libc.so.6 (0x40034000)
> libattr.so.1 => /lib/libattr.so.1 (0x40159000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40164000)

> Recompiling libacl1 (itself an awkward task since the package itself
> segfaults in the middle when it is doing something to the postinst script)
> and installing the recompiled version fixes the problem.

> -- System Information:
> Debian Release: 3.1
> APT prefers testing
> APT policy: (500, 'testing')
> Architecture: arm (armv4l)
> Kernel: Linux 2.4.18-rmk7

Do you know if upgrading to the 2.4 kernel version available in sarge makes
a difference here?

--
Steve Langasek
postmodern programmer

[Nathan Scott (nathans)]

Hi there,

On Fri, Jun 10, 2005 at 04:39:26PM -0700, Steve Langasek wrote:
> On Fri, Jun 10, 2005 at 11:36:18PM +0100, Jonathan David Amery wrote:
> > I've just upgraded my system from woody to sarge. Among other upgrade
> > problems I noticed that programmes like cp, mv and install were occasionally
> > segfaulting (and the packages that were invoking them failing to get

Could you try running cp (or getfacl, might be easier) via gdb
and getting a gdb stack trace from one of these segfaults? That
might give some more clues as to where the problem lies.

Since I've not seen this on any other platform, including the more
widely-used ones like i386, I'm guessing theres going to be something
about the arm platform thats triggering this - maybe an endian issue,
or a 32/64 bit sort of issue.

> > libacl.so.1 => /lib/libacl.so.1 (0x40026000)
> > libc.so.6 => /lib/libc.so.6 (0x40034000)
> > libattr.so.1 => /lib/libattr.so.1 (0x40159000)
> > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40164000)
>
> > Recompiling libacl1 (itself an awkward task since the package itself
> > segfaults in the middle when it is doing something to the postinst script)

Hmm, its not doing anything "special" there, so I guess we're
probably just seeing the same problem again - calls to cp or mv
in the scripts segfaulting.

> > and installing the recompiled version fixes the problem.

Oh, that is interesting. Maybe this is a gcc-arm problem, i.e. it
could have something to do with the version of gcc in use on the
build machine when this was built. So, this may in fact be a
compiler problem...?

In fact, if recompiling makes the problem go away, I think by
definition the problem cannot be in the acl/libacl1 packages,
right? Maybe I'm overlooking something though.

> Do you know if upgrading to the 2.4 kernel version available in sarge makes
> a difference here?

Anything specific you're looking for there Steve? I know the ACL
kernel patches fairly well, and nothing has changed for years now
so I'd be surprised if a kernel upgrade changed anything. Also,
the 2.4 kernels don't tend to have ACL support, although I guess
we may have patched our 2.4 kernels to include that, not sure.

cheers.

--
Nathan

[Steve Langasek (vorlon)]

On Tue, Jun 14, 2005 at 11:58:02AM +1000, Nathan Scott wrote:
> > Do you know if upgrading to the 2.4 kernel version available in sarge makes
> > a difference here?

> Anything specific you're looking for there Steve?

Yes:

  + arm: upgrade doesn't work with 2.2, but can work with 2.4.24 or above.
    (perhaps also with older versions, currently unknown)
    (details: glibc vs kernel, source: kylem, tested on netwinder)
    [*]

  http://release.debian.org/upgrade-kernel

AFAIK, this was the only discussion of minimum kernel versions for sarge
on ARM prior to release; it's very possible that either a glibc change or a
toolchain change has resulted in the current ARM libacl binaries being
usable only on later kernels than what was available in woody, due to
differing ABIs. We had a hard time finding people to test this upgrade
path, because there are apparently relatively few machines that are
compatible with the ARM kernels that shipped in woody. :/

> I know the ACL kernel patches fairly well, and nothing has changed for
> years now so I'd be surprised if a kernel upgrade changed anything.

On the contrary, libacl works sanely on kernels lacking any ACL kernel
support whatsoever -- this architecture-specific failure more likely points
to a kernel ABI issue specific to ARM.

--
Steve Langasek
postmodern programmer

[Nathan Scott (nathans)]

On Mon, Jun 13, 2005 at 07:56:13PM -0700, Steve Langasek wrote:
> On Tue, Jun 14, 2005 at 11:58:02AM +1000, Nathan Scott wrote:
> > Anything specific you're looking for there Steve?
>
> + arm: upgrade doesn't work with 2.2, but can work with 2.4.24 or above.
> (perhaps also with older versions, currently unknown)
> (details: glibc vs kernel, source: kylem, tested on netwinder)
> [*]
>
> > I know the ACL kernel patches fairly well, and nothing has changed for
> > years now so I'd be surprised if a kernel upgrade changed anything.
>
> On the contrary, libacl works sanely on kernels lacking any ACL kernel
> support whatsoever -- this architecture-specific failure more likely points
> to a kernel ABI issue specific to ARM.

Hmmm, it was interesting that a libacl recompile made the problem
go away though, that seemed to me to point toward a compiler type
issue rather than a kernel/glibc issue.

cheers.

--
Nathan

[Steve Langasek (vorlon)]

So are there any porters alive out there on debian-arm? Being unable to use
cp, mv, and install after upgrading from woody to sarge is a rather serious
problem. If anyone has any ideas about this, or can test the problem with a
woody vs. a sarge kernel, please speak up so that we can at the very least
document this in the release notes if we need to.

--
Steve Langasek
postmodern programmer

[Lennart Sorensen (lsorense)]

On Fri, Jun 24, 2005 at 02:29:19AM -0700, Steve Langasek wrote:
> So are there any porters alive out there on debian-arm? Being unable to use
> cp, mv, and install after upgrading from woody to sarge is a rather serious
> problem. If anyone has any ideas about this, or can test the problem with a
> woody vs. a sarge kernel, please speak up so that we can at the very least
> document this in the release notes if we need to.

Hmm, I started out with sarge testing on my arm systems, so I never did
a woody to sarge upgrade.

I know arm did have a problem testing this given how few systems you
could actually install woody on with an official debian kernel. Since
very few people had one of those systems around, testing the upgrade has
not been easy.

I do seem to recall there is something in the sarge release notes (or
was supposed to be) about how to upgrade arm from woody to sarge involving
getting a new kernel first, since something important changed. I
remember that happens for sure on mips, and also happens on true i386
machines (since sarge's libc requried 486 instructions, so the new
kernel emulates the few missing instructions on i386 systems).

Len Sorensen

[Steve Langasek (vorlon)]

On Fri, Jun 24, 2005 at 08:40:42AM -0400, Lennart Sorensen wrote:
> On Fri, Jun 24, 2005 at 02:29:19AM -0700, Steve Langasek wrote:
> > So are there any porters alive out there on debian-arm? Being unable to use
> > cp, mv, and install after upgrading from woody to sarge is a rather serious
> > problem. If anyone has any ideas about this, or can test the problem with a
> > woody vs. a sarge kernel, please speak up so that we can at the very least
> > document this in the release notes if we need to.

> Hmm, I started out with sarge testing on my arm systems, so I never did
> a woody to sarge upgrade.

> I know arm did have a problem testing this given how few systems you
> could actually install woody on with an official debian kernel. Since
> very few people had one of those systems around, testing the upgrade has
> not been easy.

> I do seem to recall there is something in the sarge release notes (or
> was supposed to be) about how to upgrade arm from woody to sarge involving
> getting a new kernel first, since something important changed. I
> remember that happens for sure on mips, and also happens on true i386
> machines (since sarge's libc requried 486 instructions, so the new
> kernel emulates the few missing instructions on i386 systems).

Except there isn't anything in the sarge release notes about this, because
the last thing the release team was told was that arm upgrades "should
work". So if it doesn't work, I want to know what we need to put in the
release notes. :)

--
Steve Langasek
postmodern programmer

[Andreas Barth (aba)]

retitle 312936 [arm] Programmes linked against libacl1 segfault in libacl1 code

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #312936 http://bugs.debian.org/312936

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Fri, 10 Jun 2005 23:36:18 +0100
From: Jonathan David Amery <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: Programmes linked against libacl1 segfault in libacl1 code.

Package: libacl1
Version: 2.2.23-1
Severity: critical
Justification: breaks unrelated software

I've just upgraded my system from woody to sarge. Among other upgrade
problems I noticed that programmes like cp, mv and install were occasionally
segfaulting (and the packages that were invoking them failing to get
installed), leaving register dumps like this in my logs:

  pc : [<400278ac>] lr : [<4002a348>] Not tainted
  sp : bffff4f4 ip : 40049cf8 fp : bffff780
  r10: 400333bc r9 : bffffa38 r8 : bffff548
  r7 : bffff561 r6 : 00000000 r5 : 0001c324 r4 : bffff50c
  r3 : 00000004 r2 : 00000000 r1 : 00009d6b r0 : bffff508
  Flags: nzCv IRQs on FIQs on Mode USER_32 Segment user
  Control: 1C14917D Table: 1C14917D DAC: 00000015

Looking at the ldd output for cp makes it quite clear that this is inside
libacl1:

        libacl.so.1 => /lib/libacl.so.1 (0x40026000)
        libc.so.6 => /lib/libc.so.6 (0x40034000)
        libattr.so.1 => /lib/libattr.so.1 (0x40159000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40164000)

Recompiling libacl1 (itself an awkward task since the package itself
segfaults in the middle when it is doing something to the postinst script)
and installing the recompiled version fixes the problem.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm (armv4l)
Kernel: Linux 2.4.18-rmk7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages libacl1 depends on:
ii libattr1 2.4.16-1 Extended attribute shared library
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libgcc1 1:3.4.3-13 GCC support library

-- no debconf information

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 10 Jun 2005 16:39:26 -0700
From: Steve Langasek <email address hidden>
To: Jonathan David Amery <email address hidden>,
 <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#312936: Programmes linked against libacl1 segfault in libacl1 code.

--g6DVDhPhk1bqxDrC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 10, 2005 at 11:36:18PM +0100, Jonathan David Amery wrote:
> I've just upgraded my system from woody to sarge. Among other upgrade=20
> problems I noticed that programmes like cp, mv and install were occasiona=
lly=20
> segfaulting (and the packages that were invoking them failing to get=20
> installed), leaving register dumps like this in my logs:

> pc : [<400278ac>] lr : [<4002a348>] Not tainted
> sp : bffff4f4 ip : 40049cf8 fp : bffff780
> r10: 400333bc r9 : bffffa38 r8 : bffff548
> r7 : bffff561 r6 : 00000000 r5 : 0001c324 r4 : bffff50c
> r3 : 00000004 r2 : 00000000 r1 : 00009d6b r0 : bffff508
> Flags: nzCv IRQs on FIQs on Mode USER_32 Segment user
> Control: 1C14917D Table: 1C14917D DAC: 00000015

> Looking at the ldd output for cp makes it quite clear that this is inside=
=20
> libacl1:

> libacl.so.1 =3D> /lib/libacl.so.1 (0x40026000)
> libc.so.6 =3D> /lib/libc.so.6 (0x40034000)
> libattr.so.1 =3D> /lib/libattr.so.1 (0x40159000)
> /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x40000000)
> libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x40164000)

> Recompiling libacl1 (itself an awkward task since the package itself=20
> segfaults in the middle when it is doing something to the postinst script)
> and installing the recompiled version fixes the problem.

> -- System Information:
> Debian Release: 3.1
> APT prefers testing
> APT policy: (500, 'testing')
> Architecture: arm (armv4l)
> Kernel: Linux 2.4.18-rmk7

Do you know if upgrading to the 2.4 kernel version available in sarge makes
a difference here?=20

--=20
Steve Langasek
postmodern programmer

--g6DVDhPhk1bqxDrC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFCqiStKN6ufymYLloRAsfBAKCZC7h+stBLENk5gEnXR7AAl3Gm1wCguDb6
HhucLyUlb48LET+hkIoSh80=
=/8I5
-----END PGP SIGNATURE-----

--g6DVDhPhk1bqxDrC--

[Debian Bug Importer (debzilla)]

Message-ID: <20050614015802.GA1623@frodo>
Date: Tue, 14 Jun 2005 11:58:02 +1000
From: Nathan Scott <email address hidden>
To: Jonathan David Amery <email address hidden>,
 Steve Langasek <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#312936: Programmes linked against libacl1 segfault in libacl1 code.

--/9DWx/yDrRhgMJTb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi there,

On Fri, Jun 10, 2005 at 04:39:26PM -0700, Steve Langasek wrote:
> On Fri, Jun 10, 2005 at 11:36:18PM +0100, Jonathan David Amery wrote:
> > I've just upgraded my system from woody to sarge. Among other upgrade=
=20
> > problems I noticed that programmes like cp, mv and install were occasio=
nally=20
> > segfaulting (and the packages that were invoking them failing to get=20

Could you try running cp (or getfacl, might be easier) via gdb
and getting a gdb stack trace from one of these segfaults? That
might give some more clues as to where the problem lies.

Since I've not seen this on any other platform, including the more
widely-used ones like i386, I'm guessing theres going to be something
about the arm platform thats triggering this - maybe an endian issue,
or a 32/64 bit sort of issue.

> > libacl.so.1 =3D> /lib/libacl.so.1 (0x40026000)
> > libc.so.6 =3D> /lib/libc.so.6 (0x40034000)
> > libattr.so.1 =3D> /lib/libattr.so.1 (0x40159000)
> > /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x40000000)
> > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x40164000)
>=20
> > Recompiling libacl1 (itself an awkward task since the package itself=20
> > segfaults in the middle when it is doing something to the postinst scri=
pt)

Hmm, its not doing anything "special" there, so I guess we're
probably just seeing the same problem again - calls to cp or mv
in the scripts segfaulting.

> > and installing the recompiled version fixes the problem.

Oh, that is interesting. Maybe this is a gcc-arm problem, i.e. it
could have something to do with the version of gcc in use on the
build machine when this was built. So, this may in fact be a
compiler problem...?

In fact, if recompiling makes the problem go away, I think by
definition the problem cannot be in the acl/libacl1 packages,
right? Maybe I'm overlooking something though.

> Do you know if upgrading to the 2.4 kernel version available in sarge mak=
es
> a difference here?=20

Anything specific you're looking for there Steve? I know the ACL
kernel patches fairly well, and nothing has changed for years now
so I'd be surprised if a kernel upgrade changed anything. Also,
the 2.4 kernels don't tend to have ACL support, although I guess
we may have patched our 2.4 kernels to include that, not sure.

cheers.

--=20
Nathan

--/9DWx/yDrRhgMJTb
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFCrjmqm8fl3HSIa2MRAmiBAJ43WrQmNTPf9P1BKjXDAH71TIkU+ACdHRGr
venVX6EtaxoiUWYsmpY22EM=
=JZ/d
-----END PGP SIGNATURE-----

--/9DWx/yDrRhgMJTb--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 13 Jun 2005 19:56:13 -0700
From: Steve Langasek <email address hidden>
To: Nathan Scott <email address hidden>
Cc: Jonathan David Amery <email address hidden>,
 <email address hidden>, <email address hidden>
Subject: Re: Bug#312936: Programmes linked against libacl1 segfault in libacl1 code.

--9dgjiU4MmWPVapMU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 14, 2005 at 11:58:02AM +1000, Nathan Scott wrote:
> > Do you know if upgrading to the 2.4 kernel version available in sarge m=
akes
> > a difference here?=20

> Anything specific you're looking for there Steve?

Yes:

  + arm: upgrade doesn't work with 2.2, but can work with 2.4.24 or above.
    (perhaps also with older versions, currently unknown)
    (details: glibc vs kernel, source: kylem, tested on netwinder)
    [*]

  http://release.debian.org/upgrade-kernel

AFAIK, this was the only discussion of minimum kernel versions for sarge
on ARM prior to release; it's very possible that either a glibc change or a
toolchain change has resulted in the current ARM libacl binaries being
usable only on later kernels than what was available in woody, due to
differing ABIs. We had a hard time finding people to test this upgrade
path, because there are apparently relatively few machines that are
compatible with the ARM kernels that shipped in woody. :/

> I know the ACL kernel patches fairly well, and nothing has changed for
> years now so I'd be surprised if a kernel upgrade changed anything.

On the contrary, libacl works sanely on kernels lacking any ACL kernel
support whatsoever -- this architecture-specific failure more likely points
to a kernel ABI issue specific to ARM.

--=20
Steve Langasek
postmodern programmer

--9dgjiU4MmWPVapMU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFCrkdMKN6ufymYLloRAlwFAKDALNif3dlstVU3mr+3DwXl/CHlcwCfX4hK
V1wOsfNyditwDlQxU4YgFq8=
=6XhV
-----END PGP SIGNATURE-----

--9dgjiU4MmWPVapMU--

[Debian Bug Importer (debzilla)]

Message-ID: <20050614031525.GC1623@frodo>
Date: Tue, 14 Jun 2005 13:15:25 +1000
From: Nathan Scott <email address hidden>
To: Steve Langasek <email address hidden>
Cc: Jonathan David Amery <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Re: Bug#312936: Programmes linked against libacl1 segfault in libacl1 code.

--U+BazGySraz5kW0T
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 13, 2005 at 07:56:13PM -0700, Steve Langasek wrote:
> On Tue, Jun 14, 2005 at 11:58:02AM +1000, Nathan Scott wrote:
> > Anything specific you're looking for there Steve?
>=20
> + arm: upgrade doesn't work with 2.2, but can work with 2.4.24 or above.
> (perhaps also with older versions, currently unknown)
> (details: glibc vs kernel, source: kylem, tested on netwinder)
> [*]
>=20
> > I know the ACL kernel patches fairly well, and nothing has changed for
> > years now so I'd be surprised if a kernel upgrade changed anything.
>=20
> On the contrary, libacl works sanely on kernels lacking any ACL kernel
> support whatsoever -- this architecture-specific failure more likely poin=
ts
> to a kernel ABI issue specific to ARM.

Hmmm, it was interesting that a libacl recompile made the problem
go away though, that seemed to me to point toward a compiler type
issue rather than a kernel/glibc issue.

cheers.

--=20
Nathan

--U+BazGySraz5kW0T
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFCrkvNm8fl3HSIa2MRAl5xAJ4pw9Q0tpfRjrsoaGDIWswRI7EMmACgrvhy
6CNZXBHYvSH3q7SkIU1a98k=
=0ZPU
-----END PGP SIGNATURE-----

--U+BazGySraz5kW0T--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 24 Jun 2005 02:29:19 -0700
From: Steve Langasek <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Programmes linked against libacl1 segfault in libacl1 code.

--dDRMvlgZJXvWKvBx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

So are there any porters alive out there on debian-arm? Being unable to use
cp, mv, and install after upgrading from woody to sarge is a rather serious
problem. If anyone has any ideas about this, or can test the problem with a
woody vs. a sarge kernel, please speak up so that we can at the very least
document this in the release notes if we need to.

--=20
Steve Langasek
postmodern programmer

--dDRMvlgZJXvWKvBx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFCu9JvKN6ufymYLloRArjwAJ90EMoDkP3kkaJVivsoIk7KbiRVLgCgkYZu
8rHsYDbrTs5M/n99ZQyLyhg=
=yYQD
-----END PGP SIGNATURE-----

--dDRMvlgZJXvWKvBx--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 24 Jun 2005 08:40:42 -0400
From: <email address hidden> (Lennart Sorensen)
To: Steve Langasek <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Programmes linked against libacl1 segfault in libacl1 code.

On Fri, Jun 24, 2005 at 02:29:19AM -0700, Steve Langasek wrote:
> So are there any porters alive out there on debian-arm? Being unable to use
> cp, mv, and install after upgrading from woody to sarge is a rather serious
> problem. If anyone has any ideas about this, or can test the problem with a
> woody vs. a sarge kernel, please speak up so that we can at the very least
> document this in the release notes if we need to.

Hmm, I started out with sarge testing on my arm systems, so I never did
a woody to sarge upgrade.

I know arm did have a problem testing this given how few systems you
could actually install woody on with an official debian kernel. Since
very few people had one of those systems around, testing the upgrade has
not been easy.

I do seem to recall there is something in the sarge release notes (or
was supposed to be) about how to upgrade arm from woody to sarge involving
getting a new kernel first, since something important changed. I
remember that happens for sure on mips, and also happens on true i386
machines (since sarge's libc requried 486 instructions, so the new
kernel emulates the few missing instructions on i386 systems).

Len Sorensen

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 24 Jun 2005 14:04:22 -0700
From: Steve Langasek <email address hidden>
To: Lennart Sorensen <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Programmes linked against libacl1 segfault in libacl1 code.

--9jxsPFA5p3P2qPhR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 24, 2005 at 08:40:42AM -0400, Lennart Sorensen wrote:
> On Fri, Jun 24, 2005 at 02:29:19AM -0700, Steve Langasek wrote:
> > So are there any porters alive out there on debian-arm? Being unable t=
o use
> > cp, mv, and install after upgrading from woody to sarge is a rather ser=
ious
> > problem. If anyone has any ideas about this, or can test the problem w=
ith a
> > woody vs. a sarge kernel, please speak up so that we can at the very le=
ast
> > document this in the release notes if we need to.

> Hmm, I started out with sarge testing on my arm systems, so I never did
> a woody to sarge upgrade.

> I know arm did have a problem testing this given how few systems you
> could actually install woody on with an official debian kernel. Since
> very few people had one of those systems around, testing the upgrade has
> not been easy.

> I do seem to recall there is something in the sarge release notes (or
> was supposed to be) about how to upgrade arm from woody to sarge involving
> getting a new kernel first, since something important changed. I
> remember that happens for sure on mips, and also happens on true i386
> machines (since sarge's libc requried 486 instructions, so the new
> kernel emulates the few missing instructions on i386 systems).

Except there isn't anything in the sarge release notes about this, because
the last thing the release team was told was that arm upgrades "should
work". So if it doesn't work, I want to know what we need to put in the
release notes. :)

--=20
Steve Langasek
postmodern programmer

--9jxsPFA5p3P2qPhR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFCvHVVKN6ufymYLloRAohIAKCpjqhLFpoE7+eyk6ZIIrZ8AiZwWwCgt8Qn
LfvzijH5nXTNIONHuJ2AqoQ=
=Seni
-----END PGP SIGNATURE-----

--9jxsPFA5p3P2qPhR--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 14 Aug 2005 12:13:32 +0200
From: Andreas Barth <email address hidden>
To: <email address hidden>
Subject: happens only on arm

retitle 312936 [arm] Programmes linked against libacl1 segfault in libacl1 code

[Matt Zimmerman (mdz)]

arm bug

[Nathan Scott (nathans)]

On Fri, Jun 10, 2005 at 11:36:18PM +0100, Jonathan David Amery wrote:
> ...
> Recompiling libacl1 (itself an awkward task since the package itself
> segfaults in the middle when it is doing something to the postinst script)
> and installing the recompiled version fixes the problem.

Given this statement, and the various others that suggest this may
alternatively be a kernel ABI issue, I have no reason to believe
theres actually anything wrong in the libacl package itself, nor
is there likely to any workaround that could be put into libacl.

As such, this bug is languishing assigned to libacl -- does anyone
have any suggestions as to where/how further progress could be made
on this bug? Is there a generic arm-port pseudo-package I could
reassign to? Should I just close it stating a different compiler
has resolved this (what compiler version was used above, Jonathan?)?

Any advice/suggestions, anyone?

thanks!

--
Nathan

[Steve Langasek (vorlon)]

On Mon, Aug 22, 2005 at 03:29:54PM +1000, Nathan Scott wrote:
> On Fri, Jun 10, 2005 at 11:36:18PM +0100, Jonathan David Amery wrote:
> > ...
> > Recompiling libacl1 (itself an awkward task since the package itself
> > segfaults in the middle when it is doing something to the postinst script)
> > and installing the recompiled version fixes the problem.

> Given this statement, and the various others that suggest this may
> alternatively be a kernel ABI issue, I have no reason to believe
> theres actually anything wrong in the libacl package itself, nor
> is there likely to any workaround that could be put into libacl.

> As such, this bug is languishing assigned to libacl -- does anyone
> have any suggestions as to where/how further progress could be made
> on this bug? Is there a generic arm-port pseudo-package I could
> reassign to? Should I just close it stating a different compiler
> has resolved this (what compiler version was used above, Jonathan?)?

> Any advice/suggestions, anyone?

If it *is* a kernel ABI issue, it would be appropriate for the current
libacl1 package in sarge to include a preinst check for the running
kernel version to avoid installing a known-broken combination. Please
see the libc6 preinst for an example of this.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

[Debian Bug Importer (debzilla)]

Message-ID: <20050822052954.GB1727@frodo>
Date: Mon, 22 Aug 2005 15:29:54 +1000
From: Nathan Scott <email address hidden>
To: <email address hidden>
Subject: Re: Bug#312936: Programmes linked against libacl1 segfault in libacl1 code.

On Fri, Jun 10, 2005 at 11:36:18PM +0100, Jonathan David Amery wrote:
> ...
> Recompiling libacl1 (itself an awkward task since the package itself
> segfaults in the middle when it is doing something to the postinst script)
> and installing the recompiled version fixes the problem.

Given this statement, and the various others that suggest this may
alternatively be a kernel ABI issue, I have no reason to believe
theres actually anything wrong in the libacl package itself, nor
is there likely to any workaround that could be put into libacl.

As such, this bug is languishing assigned to libacl -- does anyone
have any suggestions as to where/how further progress could be made
on this bug? Is there a generic arm-port pseudo-package I could
reassign to? Should I just close it stating a different compiler
has resolved this (what compiler version was used above, Jonathan?)?

Any advice/suggestions, anyone?

thanks!

--
Nathan

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 22 Aug 2005 00:30:01 -0700
From: Steve Langasek <email address hidden>
To: Nathan Scott <email address hidden>, <email address hidden>
Subject: Re: Bug#312936: Programmes linked against libacl1 segfault in libacl1 code.

--IiVenqGWf+H9Y6IX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 22, 2005 at 03:29:54PM +1000, Nathan Scott wrote:
> On Fri, Jun 10, 2005 at 11:36:18PM +0100, Jonathan David Amery wrote:
> > ...
> > Recompiling libacl1 (itself an awkward task since the package itself=20
> > segfaults in the middle when it is doing something to the postinst scri=
pt)
> > and installing the recompiled version fixes the problem.

> Given this statement, and the various others that suggest this may
> alternatively be a kernel ABI issue, I have no reason to believe
> theres actually anything wrong in the libacl package itself, nor
> is there likely to any workaround that could be put into libacl.

> As such, this bug is languishing assigned to libacl -- does anyone
> have any suggestions as to where/how further progress could be made
> on this bug? Is there a generic arm-port pseudo-package I could
> reassign to? Should I just close it stating a different compiler
> has resolved this (what compiler version was used above, Jonathan?)?

> Any advice/suggestions, anyone?

If it *is* a kernel ABI issue, it would be appropriate for the current
libacl1 package in sarge to include a preinst check for the running
kernel version to avoid installing a known-broken combination. Please
see the libc6 preinst for an example of this.

--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

--IiVenqGWf+H9Y6IX
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFDCX75KN6ufymYLloRArDvAKCnpz8p1Nmp7yLdbcf7sNXHgyiREACbBtGO
xwgNjZCoVPzr1cvNJPPP3jI=
=1uIK
-----END PGP SIGNATURE-----

--IiVenqGWf+H9Y6IX--

[Nathan Scott (nathans)]

On Mon, Aug 22, 2005 at 12:30:01AM -0700, Steve Langasek wrote:
> On Mon, Aug 22, 2005 at 03:29:54PM +1000, Nathan Scott wrote:
> > > ...
> > > Recompiling libacl1 (itself an awkward task since the package itself
> > > segfaults in the middle when it is doing something to the postinst script)
> > > and installing the recompiled version fixes the problem.
> > Any advice/suggestions, anyone?
>
> If it *is* a kernel ABI issue, it would be appropriate for the current
> libacl1 package in sarge to include a preinst check for the running

Yep, OK. I guess I'm not following how a kernel ABI issue
could be resolved by a re-compile though (not to say it is
not an ABI issue, just that I don't understand how).

> kernel version to avoid installing a known-broken combination. Please
> see the libc6 preinst for an example of this.

Will certainly do that if we think it will work..

thanks Steve.

--
Nathan

[Debian Bug Importer (debzilla)]

Message-ID: <20050822224309.GA743@frodo>
Date: Tue, 23 Aug 2005 08:43:09 +1000
From: Nathan Scott <email address hidden>
To: Steve Langasek <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#312936: Programmes linked against libacl1 segfault in libacl1 code.

--PNTmBPCT7hxwcZjr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 22, 2005 at 12:30:01AM -0700, Steve Langasek wrote:
> On Mon, Aug 22, 2005 at 03:29:54PM +1000, Nathan Scott wrote:
> > > ...
> > > Recompiling libacl1 (itself an awkward task since the package itself=
=20
> > > segfaults in the middle when it is doing something to the postinst sc=
ript)
> > > and installing the recompiled version fixes the problem.
> > Any advice/suggestions, anyone?
>=20
> If it *is* a kernel ABI issue, it would be appropriate for the current
> libacl1 package in sarge to include a preinst check for the running

Yep, OK. I guess I'm not following how a kernel ABI issue
could be resolved by a re-compile though (not to say it is
not an ABI issue, just that I don't understand how).

> kernel version to avoid installing a known-broken combination. Please
> see the libc6 preinst for an example of this.

Will certainly do that if we think it will work..

thanks Steve.

--=20
Nathan

--PNTmBPCT7hxwcZjr
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFDClT9m8fl3HSIa2MRAqdlAJ94u+tz1QYHRmCNRHA1FOuN0OGOMwCgq8XQ
nmxgu2Eg/rikJUyP7hHmJ2M=
=YX9p
-----END PGP SIGNATURE-----

--PNTmBPCT7hxwcZjr--

[Steve Langasek (vorlon)]

On Tue, Aug 23, 2005 at 08:43:09AM +1000, Nathan Scott wrote:
> On Mon, Aug 22, 2005 at 12:30:01AM -0700, Steve Langasek wrote:
> > On Mon, Aug 22, 2005 at 03:29:54PM +1000, Nathan Scott wrote:
> > > > ...
> > > > Recompiling libacl1 (itself an awkward task since the package itself
> > > > segfaults in the middle when it is doing something to the postinst script)
> > > > and installing the recompiled version fixes the problem.
> > > Any advice/suggestions, anyone?

> > If it *is* a kernel ABI issue, it would be appropriate for the current
> > libacl1 package in sarge to include a preinst check for the running

> Yep, OK. I guess I'm not following how a kernel ABI issue
> could be resolved by a re-compile though (not to say it is
> not an ABI issue, just that I don't understand how).

Yeah, I'm not clear on it either, which is why I was really hoping someone
from arm circles would provide some input.

Another possibility is that it's not an ABI issue in your code, but that
the binaries in the archive were somehow miscompiled, and a simple recompile
fixes it. If someone could do a rebuild of the package for arm using the
final sarge toolchain, and running an official sarge kernel, we could ask
the submitter to test that binary and get it uploaded if it's good.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 22 Aug 2005 22:44:12 -0700
From: Steve Langasek <email address hidden>
To: Nathan Scott <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#312936: Programmes linked against libacl1 segfault in libacl1 code.

--nFreZHaLTZJo0R7j
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 23, 2005 at 08:43:09AM +1000, Nathan Scott wrote:
> On Mon, Aug 22, 2005 at 12:30:01AM -0700, Steve Langasek wrote:
> > On Mon, Aug 22, 2005 at 03:29:54PM +1000, Nathan Scott wrote:
> > > > ...
> > > > Recompiling libacl1 (itself an awkward task since the package itsel=
f=20
> > > > segfaults in the middle when it is doing something to the postinst =
script)
> > > > and installing the recompiled version fixes the problem.
> > > Any advice/suggestions, anyone?

> > If it *is* a kernel ABI issue, it would be appropriate for the current
> > libacl1 package in sarge to include a preinst check for the running

> Yep, OK. I guess I'm not following how a kernel ABI issue
> could be resolved by a re-compile though (not to say it is
> not an ABI issue, just that I don't understand how).

Yeah, I'm not clear on it either, which is why I was really hoping someone
=66rom arm circles would provide some input.

Another possibility is that it's not an ABI issue in your code, but that
the binaries in the archive were somehow miscompiled, and a simple recompile
fixes it. If someone could do a rebuild of the package for arm using the
final sarge toolchain, and running an official sarge kernel, we could ask
the submitter to test that binary and get it uploaded if it's good.

--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

--nFreZHaLTZJo0R7j
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFDCresKN6ufymYLloRAnPrAKCNlDOaSXL4n6j+RV+V+KlhcUfdIACgiK/n
QlICobQlY3+PkymOGtQSCX0=
=BgVr
-----END PGP SIGNATURE-----

--nFreZHaLTZJo0R7j--

[Nathan Scott (nathans)]

severity 312936 important

--
Nathan

[Nathan Scott (nathans-sgi)]

Hi there,

Revisiting this one, again. Firstly, since we've had no other
people reporting having hit this issue, I plan to downgrade this
from a "critical" bug... I assume if it was happening to everyone
the arm port would be unusable, certainly that would be critical;
and we'd probably have made a bit of progress figuring it out by
now. :(

On Fri, Jun 10, 2005 at 11:36:18PM +0100, Jonathan David Amery wrote:
> ...
> I've just upgraded my system from woody to sarge. Among other upgrade
> problems I noticed that programmes like cp, mv and install were occasionally
> segfaulting (and the packages that were invoking them failing to get
> installed), leaving register dumps like this in my logs:
>
> pc : [<400278ac>] lr : [<4002a348>] Not tainted
> sp : bffff4f4 ip : 40049cf8 fp : bffff780
> r10: 400333bc r9 : bffffa38 r8 : bffff548
> r7 : bffff561 r6 : 00000000 r5 : 0001c324 r4 : bffff50c
> r3 : 00000004 r2 : 00000000 r1 : 00009d6b r0 : bffff508
> Flags: nzCv IRQs on FIQs on Mode USER_32 Segment user
> Control: 1C14917D Table: 1C14917D DAC: 00000015

So, its just dawned on me - you're saying these dumps are in
your system log? That would suggest this is a kernel panic,
or am I misunderstanding you there?

The above trace does look like it may be the start of a kernel
panic trace - was there anything else in the log? (eg. just
prior, or a stack trace following the above?). I'm not at all
familiar with how a kernel panic is reported on arm though.
On i386, however, a kernel panic will result in something like
the above being dumped (cpu register contents), followed by a
stack trace, and the userspace program will typically get a
SEGV (similar to what you described)... & the kernel struggles
on (basically, sounds exactly likely what you described).

cheers.

--
Nathan

[Debian Bug Importer (debzilla)]

Message-ID: <20050909052010.GG743@frodo>
Date: Fri, 9 Sep 2005 15:20:10 +1000
From: Nathan Scott <email address hidden>
To: Jonathan David Amery <email address hidden>, <email address hidden>
Subject: Re: Bug#312936: Programmes linked against libacl1 segfault in libacl1 code.

Hi there,

Revisiting this one, again. Firstly, since we've had no other
people reporting having hit this issue, I plan to downgrade this
=66rom a "critical" bug... I assume if it was happening to everyone
the arm port would be unusable, certainly that would be critical;
and we'd probably have made a bit of progress figuring it out by
now. :(

On Fri, Jun 10, 2005 at 11:36:18PM +0100, Jonathan David Amery wrote:
> ...
> I've just upgraded my system from woody to sarge. Among other upgrade=20
> problems I noticed that programmes like cp, mv and install were occasiona=
lly=20
> segfaulting (and the packages that were invoking them failing to get=20
> installed), leaving register dumps like this in my logs:
>=20
> pc : [<400278ac>] lr : [<4002a348>] Not tainted
> sp : bffff4f4 ip : 40049cf8 fp : bffff780
> r10: 400333bc r9 : bffffa38 r8 : bffff548
> r7 : bffff561 r6 : 00000000 r5 : 0001c324 r4 : bffff50c
> r3 : 00000004 r2 : 00000000 r1 : 00009d6b r0 : bffff508
> Flags: nzCv IRQs on FIQs on Mode USER_32 Segment user
> Control: 1C14917D Table: 1C14917D DAC: 00000015

So, its just dawned on me - you're saying these dumps are in
your system log? That would suggest this is a kernel panic,
or am I misunderstanding you there?

The above trace does look like it may be the start of a kernel
panic trace - was there anything else in the log? (eg. just
prior, or a stack trace following the above?). I'm not at all
familiar with how a kernel panic is reported on arm though.
On i386, however, a kernel panic will result in something like
the above being dumped (cpu register contents), followed by a
stack trace, and the userspace program will typically get a
SEGV (similar to what you described)... & the kernel struggles
on (basically, sounds exactly likely what you described).

cheers.

--=20
Nathan

[Debian Bug Importer (debzilla)]

Message-ID: <20050909052613.GH743@frodo>
Date: Fri, 9 Sep 2005 15:26:13 +1000
From: Nathan Scott <email address hidden>
To: <email address hidden>

severity 312936 important

--
Nathan