Bug#554574: libstdc++6: apt segfaults on hppa

[Domenico Andreoli-3]

Package: libstdc++6
Version: 4.4.2-2
Severity: grave

Hi,

  after this morning upgrade apt started to systematically segfault
on my hppa box, not even an update was allowed. i reported this on the
hppa porters list [0].

of course suspect no. 1 is the NPTL switch but downgrading eglibc to
2.10.1-3 or even -2 did not improve the situation. i also tried with
standard kernel 2.6.30-2-parisc-smp (at that moment i was running
2.6.32-rc5) but still nothing.

then i tried to rebuild apt with the latest stuff, just in case NPTL
switch introduced any compatibility issue but g++ died at least one
time during usual autoconf g++ usability tests.

finally i tried downgrading libstdc++6 to 4.4.2-1 and it looks like
the problem is gone. indeed this package was upgraded this morning.

in the meanwhile 2.6.32-rc6 had been built and booted nicely. i've
then been able to use apt again and re-upgraded eglibc to 2.10.1-5 and
everything still works.

upgrading g++-4.4 & related stuff back to 4.4.2-2 not only reintroduces
the problem but it does not even get past the whole process dying before
the end. downgrading to 4.4.2-1 settles everything again.

frankly i do not know what to do next, besides trying to rebuild gcc-4.4
4.4.2-1 with latest eglibc to see if it is the culprit or it is rather
the svn merge between gcc 4.4.2-1 and -2.

thanks,
Domenico

[0] http://lists.debian.org/debian-hppa/2009/11/msg00005.html


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: hppa (parisc)

Kernel: Linux 2.6.32-rc6 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=it_IT (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages libstdc++6 depends on:
hi  gcc-4.4-base                  4.4.2-1    The GNU Compiler Collection (base
ii  libc6                         2.10.1-5   GNU C Library: Shared libraries
hi  libgcc4                       4.4.2-1    GCC support library

libstdc++6 recommends no packages.

libstdc++6 suggests no packages.

-- no debconf information


-----[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Matthias Klose]

On 05.11.2009 14:30, Domenico Andreoli wrote:

> Package: libstdc++6
> Version: 4.4.2-2
> Severity: grave
>
> Hi,
>
>    after this morning upgrade apt started to systematically segfault
> on my hppa box, not even an update was allowed. i reported this on the
> hppa porters list [0].
>
> of course suspect no. 1 is the NPTL switch but downgrading eglibc to
> 2.10.1-3 or even -2 did not improve the situation. i also tried with
> standard kernel 2.6.30-2-parisc-smp (at that moment i was running
> 2.6.32-rc5) but still nothing.
>
> then i tried to rebuild apt with the latest stuff, just in case NPTL
> switch introduced any compatibility issue but g++ died at least one
> time during usual autoconf g++ usability tests.
>
> finally i tried downgrading libstdc++6 to 4.4.2-1 and it looks like
> the problem is gone. indeed this package was upgraded this morning.
>
> in the meanwhile 2.6.32-rc6 had been built and booted nicely. i've
> then been able to use apt again and re-upgraded eglibc to 2.10.1-5 and
> everything still works.
>
> upgrading g++-4.4&  related stuff back to 4.4.2-2 not only reintroduces
> the problem but it does not even get past the whole process dying before
> the end. downgrading to 4.4.2-1 settles everything again.
>
> frankly i do not know what to do next, besides trying to rebuild gcc-4.4
> 4.4.2-1 with latest eglibc to see if it is the culprit

or rebuild against eglibc-2.9. could you do this as a test?

> or it is rather
> the svn merge between gcc 4.4.2-1 and -2.


test results for 4.4.2-1:
   http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01919.html
for 4.4.2-2:
   http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00351.html

there are some differences, which are not seen in Dave's build:
   http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00047.html

there are some parisc scpecific changes:

2009-10-23  John David Anglin  <dave.anglin@...>

         Backport from mainline:
         2009-08-19  John David Anglin  <dave.anglin@...>

         * pa.md (reload_inhi, reload_outhi, reload_inqi, reload_outqi): New
         patterns.
         * pa.c (emit_move_sequence): Check if address of operand1 is valid
         for mode mode of operand0 when doing secondary reload for SAR.

2009-10-20  John David Anglin  <dave.anglin@...>

         Backport from mainline:
         2009-10-15  John David Anglin  <dave.anglin@...>

         PR target/41702
         * pa.md (casesi): Use sign extended index in call to
         gen_casesi64p.
         (casesi64p): Update pattern to reflect above.

>
> thanks,
> Domenico
>
> [0] http://lists.debian.org/debian-hppa/2009/11/msg00005.html
>
>
> -- System Information:
> Debian Release: squeeze/sid
>    APT prefers unstable
>    APT policy: (990, 'unstable'), (1, 'experimental')
> Architecture: hppa (parisc)
>
> Kernel: Linux 2.6.32-rc6 (SMP w/2 CPU cores)
> Locale: LANG=C, LC_CTYPE=it_IT (charmap=ISO-8859-1)
> Shell: /bin/sh linked to /bin/bash
>
> Versions of packages libstdc++6 depends on:
> hi  gcc-4.4-base                  4.4.2-1    The GNU Compiler Collection (base
> ii  libc6                         2.10.1-5   GNU C Library: Shared libraries
> hi  libgcc4                       4.4.2-1    GCC support library

--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Domenico Andreoli-5]

On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klose <doko@...> wrote:
> On 05.11.2009 14:30, Domenico Andreoli wrote:
>>
>> frankly i do not know what to do next, besides trying to rebuild gcc-4.4
>> 4.4.2-1 with latest eglibc to see if it is the culprit
>
> or rebuild against eglibc-2.9. could you do this as a test?

yes, build started

-----[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Domenico Andreoli-3]

On Thu, Nov 05, 2009 at 06:47:11PM +0100, Domenico Andreoli wrote:
> On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klose <doko@...> wrote:
> > On 05.11.2009 14:30, Domenico Andreoli wrote:
> >>
> >> frankly i do not know what to do next, besides trying to rebuild gcc-4.4
> >> 4.4.2-1 with latest eglibc to see if it is the culprit
> >
> > or rebuild against eglibc-2.9. could you do this as a test?
>
> yes, build started

the gcc 4.4.2-2 built with eglibc 2.9-25 has not the problem and current
gcc 4.4.2-1 is built with eglibc 2.9-26 [0].  should i try building
4.4.2-1 with eglibc 2.10.1-5 or are we convinced it is NPTL?

in case anyone is interested, the binaries and the build log are here:

  https://mnl.crema.unimi.it/~cavok/gcc-4.4_4.4.2-2

regards,
Domenico

[0] https://buildd.debian.org/fetch.cgi?&pkg=gcc-4.4&ver=4.4.2-1&arch=hppa&stamp=1255927737&file=log

-----[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[John David Anglin-4]

> test results for 4.4.2-1:
>    http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01919.html
> for 4.4.2-2:
>    http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00351.html
>
> there are some differences, which are not seen in Dave's build:
>    http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00047.html

For a release, I wouldn't use cloog/ppl.  It seems to cause some
loop optimization bugs.  There's also an unresolved issue with
pch on the 4.4 branch.  I usually configure with --disable-libstdcxx-pch
on the 4.4 branch.  The problem seems to be fixed on head.

> there are some parisc scpecific changes:
>
> 2009-10-23  John David Anglin  <dave.anglin@...>
>
>          Backport from mainline:
>          2009-08-19  John David Anglin  <dave.anglin@...>
>
>          * pa.md (reload_inhi, reload_outhi, reload_inqi, reload_outqi): New
>          patterns.
>          * pa.c (emit_move_sequence): Check if address of operand1 is valid
>          for mode mode of operand0 when doing secondary reload for SAR.
>
> 2009-10-20  John David Anglin  <dave.anglin@...>
>
>          Backport from mainline:
>          2009-10-15  John David Anglin  <dave.anglin@...>
>
>          PR target/41702
>          * pa.md (casesi): Use sign extended index in call to
>          gen_casesi64p.
>          (casesi64p): Update pattern to reflect above.

I doubt either of these is the problem.  The latter is specific to
hppa64.  The former is to fix an ICE compiling recent linux kernels.

Dave
--
J. David Anglin                                  dave.anglin@...
National Research Council of Canada              [phone] (FAX: [phone])



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Matthias Klose]

On 08.11.2009 21:38, John David Anglin wrote:

>> test results for 4.4.2-1:
>>     http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01919.html
>> for 4.4.2-2:
>>     http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00351.html
>>
>> there are some differences, which are not seen in Dave's build:
>>     http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00047.html
>
> For a release, I wouldn't use cloog/ppl.  It seems to cause some
> loop optimization bugs.

does this really hurt, unless the loop opts are used?

> There's also an unresolved issue with
> pch on the 4.4 branch.  I usually configure with --disable-libstdcxx-pch
> on the 4.4 branch.  The problem seems to be fixed on head.

ok, I'll add this for hppa.

   Matthias



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[John David Anglin-4]

> On 08.11.2009 21:38, John David Anglin wrote:
> >> test results for 4.4.2-1:
> >>     http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01919.html
> >> for 4.4.2-2:
> >>     http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00351.html
> >>
> >> there are some differences, which are not seen in Dave's build:
> >>     http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00047.html
> >
> > For a release, I wouldn't use cloog/ppl.  It seems to cause some
> > loop optimization bugs.
>
> does this really hurt, unless the loop opts are used?

The testsuite fails that seem related to this are:
FAIL: libgomp.c/omp-loop03.c execution test
FAIL: libgomp.c++/loop-3.C  -O  execution test
FAIL: 29_atomics/atomic_flag/clear/1.c execution test
FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test
FAIL: tr1/8_c_compatibility/complex/overloads_float.cc (test for excess errors)
FAIL: tr1/8_c_compatibility/complex/overloads_int.cc (test for excess errors)

and possibly

FAIL: abi_check

> > There's also an unresolved issue with
> > pch on the 4.4 branch.  I usually configure with --disable-libstdcxx-pch
> > on the 4.4 branch.  The problem seems to be fixed on head.
>
> ok, I'll add this for hppa.

The testsuite fails related to the pch bug are:
FAIL: 26_numerics/complex/13450.cc (test for excess errors)
FAIL: 26_numerics/complex/pow.cc (test for excess errors)

Dave
--
J. David Anglin                                  dave.anglin@...
National Research Council of Canada              [phone] (FAX: [phone])



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[John David Anglin-4]

> On 08.11.2009 21:38, John David Anglin wrote:
> >> test results for 4.4.2-1:
> >>     http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01919.html
> >> for 4.4.2-2:
> >>     http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00351.html
> >>
> >> there are some differences, which are not seen in Dave's build:
> >>     http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00047.html
> >
> > For a release, I wouldn't use cloog/ppl.  It seems to cause some
> > loop optimization bugs.
>
> does this really hurt, unless the loop opts are used?

Compare above with
http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00812.html

Dave
--
J. David Anglin                                  dave.anglin@...
National Research Council of Canada              [phone] (FAX: [phone])



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

Domenico Andreoli a écrit :

> On Thu, Nov 05, 2009 at 06:47:11PM +0100, Domenico Andreoli wrote:
>> On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klose <doko@...> wrote:
>>> On 05.11.2009 14:30, Domenico Andreoli wrote:
>>>> frankly i do not know what to do next, besides trying to rebuild gcc-4.4
>>>> 4.4.2-1 with latest eglibc to see if it is the culprit
>>> or rebuild against eglibc-2.9. could you do this as a test?
>> yes, build started
>
> the gcc 4.4.2-2 built with eglibc 2.9-25 has not the problem and current
> gcc 4.4.2-1 is built with eglibc 2.9-26 [0].  should i try building
> 4.4.2-1 with eglibc 2.10.1-5 or are we convinced it is NPTL?

At least we are convinced it's eglibc 2.10.1, not 100% sure it is due to
NPTL.

I have done some more tests, showing it's a bit more complicated than
that. apt-get from stable/testing/unstable:
- works with libstdc++6 built against eglibc 2.9
- segfaults with libstdc++6 built against eglibc 2.10.1

Then I tried to rebuild apt against the "broken" libstdc++6.
Surprisingly this new apt-get:
- works with libstdc++6 built against eglibc 2.10.1
- segfaults with libstdc++6 built against eglibc 2.9

So in short, it seems that using eglibc 2.10.1 to build libstdc++6
triggers an ABI change on this library. I haven't investigated more for
now, I am not sure when I'll have time to do it.

--
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@...                 http://www.aurel32.net



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Fri, Nov 20, 2009 at 10:31 AM, Aurelien Jarno <aurelien@...> wrote:

> Domenico Andreoli a écrit :
>> On Thu, Nov 05, 2009 at 06:47:11PM +0100, Domenico Andreoli wrote:
>>> On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klose <doko@...> wrote:
>>>> On 05.11.2009 14:30, Domenico Andreoli wrote:
>>>>> frankly i do not know what to do next, besides trying to rebuild gcc-4.4
>>>>> 4.4.2-1 with latest eglibc to see if it is the culprit
>>>> or rebuild against eglibc-2.9. could you do this as a test?
>>> yes, build started
>>
>> the gcc 4.4.2-2 built with eglibc 2.9-25 has not the problem and current
>> gcc 4.4.2-1 is built with eglibc 2.9-26 [0].  should i try building
>> 4.4.2-1 with eglibc 2.10.1-5 or are we convinced it is NPTL?
>
> At least we are convinced it's eglibc 2.10.1, not 100% sure it is due to
> NPTL.
>
> I have done some more tests, showing it's a bit more complicated than
> that. apt-get from stable/testing/unstable:
> - works with libstdc++6 built against eglibc 2.9
> - segfaults with libstdc++6 built against eglibc 2.10.1
>
> Then I tried to rebuild apt against the "broken" libstdc++6.
> Surprisingly this new apt-get:
> - works with libstdc++6 built against eglibc 2.10.1
> - segfaults with libstdc++6 built against eglibc 2.9
>
> So in short, it seems that using eglibc 2.10.1 to build libstdc++6
> triggers an ABI change on this library. I haven't investigated more for
> now, I am not sure when I'll have time to do it.

This is not surprising, Dave has already pointed out that the debian
libstdc++6 testsuite run clearly has an ABI failure e.g.
~~~
FAIL: abi_check
~~~

I'm running a build with --without-cloog/--without-ppl to see if that
corrects the testsuite failures.

We need to stop allowing packages to build if the testsuite runs aren't clean.

Cheers,
Carlos.



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

On Fri, Nov 20, 2009 at 05:44:25PM -0500, Carlos O'Donell wrote:

> On Fri, Nov 20, 2009 at 10:31 AM, Aurelien Jarno <aurelien@...> wrote:
> > Domenico Andreoli a écrit :
> >> On Thu, Nov 05, 2009 at 06:47:11PM +0100, Domenico Andreoli wrote:
> >>> On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klose <doko@...> wrote:
> >>>> On 05.11.2009 14:30, Domenico Andreoli wrote:
> >>>>> frankly i do not know what to do next, besides trying to rebuild gcc-4.4
> >>>>> 4.4.2-1 with latest eglibc to see if it is the culprit
> >>>> or rebuild against eglibc-2.9. could you do this as a test?
> >>> yes, build started
> >>
> >> the gcc 4.4.2-2 built with eglibc 2.9-25 has not the problem and current
> >> gcc 4.4.2-1 is built with eglibc 2.9-26 [0].  should i try building
> >> 4.4.2-1 with eglibc 2.10.1-5 or are we convinced it is NPTL?
> >
> > At least we are convinced it's eglibc 2.10.1, not 100% sure it is due to
> > NPTL.
> >
> > I have done some more tests, showing it's a bit more complicated than
> > that. apt-get from stable/testing/unstable:
> > - works with libstdc++6 built against eglibc 2.9
> > - segfaults with libstdc++6 built against eglibc 2.10.1
> >
> > Then I tried to rebuild apt against the "broken" libstdc++6.
> > Surprisingly this new apt-get:
> > - works with libstdc++6 built against eglibc 2.10.1
> > - segfaults with libstdc++6 built against eglibc 2.9
> >
> > So in short, it seems that using eglibc 2.10.1 to build libstdc++6
> > triggers an ABI change on this library. I haven't investigated more for
> > now, I am not sure when I'll have time to do it.
>
> This is not surprising, Dave has already pointed out that the debian
> libstdc++6 testsuite run clearly has an ABI failure e.g.
> ~~~
> FAIL: abi_check
> ~~~
>

This test actually fails for both old and new version, I actually don't
know for how long it fails.

Also comparing the two versions with the extract_symvers scripts from
gcc sources doesn't show any difference. Looks like the problem is a bit
more complex than it seems.

--
Aurelien Jarno                        GPG: 1024D/F1BCDB73
aurelien@...                 http://www.aurel32.net



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

On Fri, Nov 20, 2009 at 11:52:36PM +0100, Aurelien Jarno wrote:

> On Fri, Nov 20, 2009 at 05:44:25PM -0500, Carlos O'Donell wrote:
> > On Fri, Nov 20, 2009 at 10:31 AM, Aurelien Jarno <aurelien@...> wrote:
> > > Domenico Andreoli a écrit :
> > >> On Thu, Nov 05, 2009 at 06:47:11PM +0100, Domenico Andreoli wrote:
> > >>> On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klose <doko@...> wrote:
> > >>>> On 05.11.2009 14:30, Domenico Andreoli wrote:
> > >>>>> frankly i do not know what to do next, besides trying to rebuild gcc-4.4
> > >>>>> 4.4.2-1 with latest eglibc to see if it is the culprit
> > >>>> or rebuild against eglibc-2.9. could you do this as a test?
> > >>> yes, build started
> > >>
> > >> the gcc 4.4.2-2 built with eglibc 2.9-25 has not the problem and current
> > >> gcc 4.4.2-1 is built with eglibc 2.9-26 [0].  should i try building
> > >> 4.4.2-1 with eglibc 2.10.1-5 or are we convinced it is NPTL?
> > >
> > > At least we are convinced it's eglibc 2.10.1, not 100% sure it is due to
> > > NPTL.
> > >
> > > I have done some more tests, showing it's a bit more complicated than
> > > that. apt-get from stable/testing/unstable:
> > > - works with libstdc++6 built against eglibc 2.9
> > > - segfaults with libstdc++6 built against eglibc 2.10.1
> > >
> > > Then I tried to rebuild apt against the "broken" libstdc++6.
> > > Surprisingly this new apt-get:
> > > - works with libstdc++6 built against eglibc 2.10.1
> > > - segfaults with libstdc++6 built against eglibc 2.9
> > >
> > > So in short, it seems that using eglibc 2.10.1 to build libstdc++6
> > > triggers an ABI change on this library. I haven't investigated more for
> > > now, I am not sure when I'll have time to do it.
> >
> > This is not surprising, Dave has already pointed out that the debian
> > libstdc++6 testsuite run clearly has an ABI failure e.g.
> > ~~~
> > FAIL: abi_check
> > ~~~
> >
>
> This test actually fails for both old and new version, I actually don't
> know for how long it fails.
>

I am wrong on that, I compared squeeze and sid versions, which both
fails. Here are the results for the last few versions:

4.4.1-4: fail (glibc 2.9) (squeeze)
4.4.1-5: fail (glibc 2.9)
4.4.1-6: fail (glibc 2.9)
4.4.2-1: pass (glibc 2.9)
4.4.2-2: fail (glibc 2.10) (sid)

--
Aurelien Jarno                        GPG: 1024D/F1BCDB73
aurelien@...                 http://www.aurel32.net



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Matthias Klose]

On 20.11.2009 16:44, Carlos O'Donell wrote:

> On Fri, Nov 20, 2009 at 10:31 AM, Aurelien Jarno<aurelien@...>  wrote:
>> Domenico Andreoli a écrit :
>>> On Thu, Nov 05, 2009 at 06:47:11PM +0100, Domenico Andreoli wrote:
>>>> On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klose<doko@...>  wrote:
>>>>> On 05.11.2009 14:30, Domenico Andreoli wrote:
>>>>>> frankly i do not know what to do next, besides trying to rebuild gcc-4.4
>>>>>> 4.4.2-1 with latest eglibc to see if it is the culprit
>>>>> or rebuild against eglibc-2.9. could you do this as a test?
>>>> yes, build started
>>>
>>> the gcc 4.4.2-2 built with eglibc 2.9-25 has not the problem and current
>>> gcc 4.4.2-1 is built with eglibc 2.9-26 [0].  should i try building
>>> 4.4.2-1 with eglibc 2.10.1-5 or are we convinced it is NPTL?
>>
>> At least we are convinced it's eglibc 2.10.1, not 100% sure it is due to
>> NPTL.
>>
>> I have done some more tests, showing it's a bit more complicated than
>> that. apt-get from stable/testing/unstable:
>> - works with libstdc++6 built against eglibc 2.9
>> - segfaults with libstdc++6 built against eglibc 2.10.1
>>
>> Then I tried to rebuild apt against the "broken" libstdc++6.
>> Surprisingly this new apt-get:
>> - works with libstdc++6 built against eglibc 2.10.1
>> - segfaults with libstdc++6 built against eglibc 2.9
>>
>> So in short, it seems that using eglibc 2.10.1 to build libstdc++6
>> triggers an ABI change on this library. I haven't investigated more for
>> now, I am not sure when I'll have time to do it.
>
> This is not surprising, Dave has already pointed out that the debian
> libstdc++6 testsuite run clearly has an ABI failure e.g.
> ~~~
> FAIL: abi_check
> ~~~

I don't have a build around, but isn't this due to the one symbol accidentally
exported in an earlier libstdc++ version?

   * Address PR libstdc++/39491, removing __signbitl from the libstdc++6
     symbols file on hppa.

> I'm running a build with --without-cloog/--without-ppl to see if that
> corrects the testsuite failures.

I doubt it; this only enables optimization options which are not turned on by
default and not used to build g++/libstdc++. The Debian packages for ppl and
cloog and ppl pass the testsuites on all archs. if you know of further tests
which could be run in Debian, please let me know.

> We need to stop allowing packages to build if the testsuite runs aren't clean.

yes, or run the testsuite at all (for hppa64-linux-gnu). I'll look into
re-enabling checks, but in the past the existing comparision checks are either
not working or unreliable for bi/triarch builds.

   Matthias

PS: offline for the next week



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

On Fri, Nov 20, 2009 at 07:00:26PM -0600, Matthias Klose wrote:

> On 20.11.2009 16:44, Carlos O'Donell wrote:
>> On Fri, Nov 20, 2009 at 10:31 AM, Aurelien Jarno<aurelien@...>  wrote:
>>> Domenico Andreoli a écrit :
>>>> On Thu, Nov 05, 2009 at 06:47:11PM +0100, Domenico Andreoli wrote:
>>>>> On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klose<doko@...>  wrote:
>>>>>> On 05.11.2009 14:30, Domenico Andreoli wrote:
>>>>>>> frankly i do not know what to do next, besides trying to rebuild gcc-4.4
>>>>>>> 4.4.2-1 with latest eglibc to see if it is the culprit
>>>>>> or rebuild against eglibc-2.9. could you do this as a test?
>>>>> yes, build started
>>>>
>>>> the gcc 4.4.2-2 built with eglibc 2.9-25 has not the problem and current
>>>> gcc 4.4.2-1 is built with eglibc 2.9-26 [0].  should i try building
>>>> 4.4.2-1 with eglibc 2.10.1-5 or are we convinced it is NPTL?
>>>
>>> At least we are convinced it's eglibc 2.10.1, not 100% sure it is due to
>>> NPTL.
>>>
>>> I have done some more tests, showing it's a bit more complicated than
>>> that. apt-get from stable/testing/unstable:
>>> - works with libstdc++6 built against eglibc 2.9
>>> - segfaults with libstdc++6 built against eglibc 2.10.1
>>>
>>> Then I tried to rebuild apt against the "broken" libstdc++6.
>>> Surprisingly this new apt-get:
>>> - works with libstdc++6 built against eglibc 2.10.1
>>> - segfaults with libstdc++6 built against eglibc 2.9
>>>
>>> So in short, it seems that using eglibc 2.10.1 to build libstdc++6
>>> triggers an ABI change on this library. I haven't investigated more for
>>> now, I am not sure when I'll have time to do it.
>>
>> This is not surprising, Dave has already pointed out that the debian
>> libstdc++6 testsuite run clearly has an ABI failure e.g.
>> ~~~
>> FAIL: abi_check
>> ~~~
>
> I don't have a build around, but isn't this due to the one symbol
> accidentally exported in an earlier libstdc++ version?
>
>   * Address PR libstdc++/39491, removing __signbitl from the libstdc++6
>     symbols file on hppa.
>

I confirm, it's what I see in the testsuite log:

| 77
| __signbitl
| version status: incompatible
| GLIBCXX_3.4
| type: function
| status: added

--
Aurelien Jarno                        GPG: 1024D/F1BCDB73
aurelien@...                 http://www.aurel32.net



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Sat, Nov 21, 2009 at 5:37 AM, Aurelien Jarno <aurelien@...> wrote:
>
> I confirm, it's what I see in the testsuite log:
>
> | 77
> | __signbitl
> | version status: incompatible
> | GLIBCXX_3.4
> | type: function
> | status: added

If __signbitl is the only failure in the abi_check, then that's easy
to fix, the testsuite needs to be updated.

With cloog/ppl disabled I still get 7 testsuite failures, so I'll have
to dig into each failure tommorow and see what's wrong.

~~~
Running target unix
FAIL: abi_check
FAIL: 26_numerics/complex/13450.cc (test for excess errors)
UNRESOLVED: 26_numerics/complex/13450.cc compilation failed to produce
executable
FAIL: 26_numerics/complex/pow.cc (test for excess errors)
UNRESOLVED: 26_numerics/complex/pow.cc compilation failed to produce executable
XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test
for excess errors)
FAIL: 29_atomics/atomic_flag/clear/1.c execution test
FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test
FAIL: tr1/8_c_compatibility/complex/overloads_float.cc (test for excess errors)
FAIL: tr1/8_c_compatibility/complex/overloads_int.cc (test for excess errors)
UNRESOLVED: tr1/8_c_compatibility/complex/overloads_int.cc compilation
failed to produce executable

                === libstdc++ Summary ===

# of expected passes            5873
# of unexpected failures        7
# of unexpected successes       1
# of expected failures          79
# of unresolved testcases       3
# of unsupported tests          331
~~~

Cheers,
Carlos.



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[John David Anglin-4]

>
> On Sat, Nov 21, 2009 at 5:37 AM, Aurelien Jarno <aurelien@...> wrote:
> >
> > I confirm, it's what I see in the testsuite log:
> >
> > | 77
> > | __signbitl
> > | version status: incompatible
> > | GLIBCXX_3.4
> > | type: function
> > | status: added
>
> If __signbitl is the only failure in the abi_check, then that's easy
> to fix, the testsuite needs to be updated.

The fail is somewhat puzzling because the problem is supposed fixed
in the 4.4 branch.

> With cloog/ppl disabled I still get 7 testsuite failures, so I'll have
> to dig into each failure tommorow and see what's wrong.
>
> ~~~
> Running target unix
> FAIL: abi_check
> FAIL: 26_numerics/complex/13450.cc (test for excess errors)
> UNRESOLVED: 26_numerics/complex/13450.cc compilation failed to produce
> executable
> FAIL: 26_numerics/complex/pow.cc (test for excess errors)
> UNRESOLVED: 26_numerics/complex/pow.cc compilation failed to produce executable
> XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test
> for excess errors)
> FAIL: 29_atomics/atomic_flag/clear/1.c execution test
> FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test
> FAIL: tr1/8_c_compatibility/complex/overloads_float.cc (test for excess errors)
> FAIL: tr1/8_c_compatibility/complex/overloads_int.cc (test for excess errors)
> UNRESOLVED: tr1/8_c_compatibility/complex/overloads_int.cc compilation
> failed to produce executable

Try adding --disable-libstdcxx-pch as mentioned earlier in this thread.
This is PR 39355: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

Good luck in debugging this bug!  I was not able to determine the
actual cause.  It appears GCC's internal data are somewhat corrupt
when the pch header files are generated.  This causes various tests
to ICE when compiled with the pch headers.

The problem appears to have gone away with head.  I don't see it with
hpux.

Dave
--
J. David Anglin                                  dave.anglin@...
National Research Council of Canada              [phone] (FAX: [phone])



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

On Sat, Nov 21, 2009 at 08:55:12PM -0500, Carlos O'Donell wrote:

> On Sat, Nov 21, 2009 at 5:37 AM, Aurelien Jarno <aurelien@...> wrote:
> >
> > I confirm, it's what I see in the testsuite log:
> >
> > | 77
> > | __signbitl
> > | version status: incompatible
> > | GLIBCXX_3.4
> > | type: function
> > | status: added
>
> If __signbitl is the only failure in the abi_check, then that's easy
> to fix, the testsuite needs to be updated.

For the testsuite part yes, but not the segfault :(

> With cloog/ppl disabled I still get 7 testsuite failures, so I'll have
> to dig into each failure tommorow and see what's wrong.
>
> ~~~
> Running target unix
> FAIL: abi_check
> FAIL: 26_numerics/complex/13450.cc (test for excess errors)
> UNRESOLVED: 26_numerics/complex/13450.cc compilation failed to produce
> executable
> FAIL: 26_numerics/complex/pow.cc (test for excess errors)
> UNRESOLVED: 26_numerics/complex/pow.cc compilation failed to produce executable
> XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test
> for excess errors)
> FAIL: 29_atomics/atomic_flag/clear/1.c execution test
> FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test
> FAIL: tr1/8_c_compatibility/complex/overloads_float.cc (test for excess errors)
> FAIL: tr1/8_c_compatibility/complex/overloads_int.cc (test for excess errors)
> UNRESOLVED: tr1/8_c_compatibility/complex/overloads_int.cc compilation
> failed to produce executable
>

Does the resulting binary works correctly with apt-get?

--
Aurelien Jarno                        GPG: 1024D/F1BCDB73
aurelien@...                 http://www.aurel32.net



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

On Sat, Nov 21, 2009 at 10:00:59PM -0500, John David Anglin wrote:

> >
> > On Sat, Nov 21, 2009 at 5:37 AM, Aurelien Jarno <aurelien@...> wrote:
> > >
> > > I confirm, it's what I see in the testsuite log:
> > >
> > > | 77
> > > | __signbitl
> > > | version status: incompatible
> > > | GLIBCXX_3.4
> > > | type: function
> > > | status: added
> >
> > If __signbitl is the only failure in the abi_check, then that's easy
> > to fix, the testsuite needs to be updated.
>
> The fail is somewhat puzzling because the problem is supposed fixed
> in the 4.4 branch.
>
> > With cloog/ppl disabled I still get 7 testsuite failures, so I'll have
> > to dig into each failure tommorow and see what's wrong.
> >
> > ~~~
> > Running target unix
> > FAIL: abi_check
> > FAIL: 26_numerics/complex/13450.cc (test for excess errors)
> > UNRESOLVED: 26_numerics/complex/13450.cc compilation failed to produce
> > executable
> > FAIL: 26_numerics/complex/pow.cc (test for excess errors)
> > UNRESOLVED: 26_numerics/complex/pow.cc compilation failed to produce executable
> > XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test
> > for excess errors)
> > FAIL: 29_atomics/atomic_flag/clear/1.c execution test
> > FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test
> > FAIL: tr1/8_c_compatibility/complex/overloads_float.cc (test for excess errors)
> > FAIL: tr1/8_c_compatibility/complex/overloads_int.cc (test for excess errors)
> > UNRESOLVED: tr1/8_c_compatibility/complex/overloads_int.cc compilation
> > failed to produce executable
>
> Try adding --disable-libstdcxx-pch as mentioned earlier in this thread.
> This is PR 39355: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
>
> Good luck in debugging this bug!  I was not able to determine the
> actual cause.  It appears GCC's internal data are somewhat corrupt
> when the pch header files are generated.  This causes various tests
> to ICE when compiled with the pch headers.
>
> The problem appears to have gone away with head.  I don't see it with
> hpux.
>

Note that latest version of gcc 4.4 in Debian is built with
--disable-libstdcxx-pch, but the segfault is this present :(

--
Aurelien Jarno                        GPG: 1024D/F1BCDB73
aurelien@...                 http://www.aurel32.net



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[John David Anglin-4]

> > The problem appears to have gone away with head.  I don't see it with
> > hpux.
> >
>
> Note that latest version of gcc 4.4 in Debian is built with
> --disable-libstdcxx-pch, but the segfault is this present :(

Personally, I don't believe the segfault is related to the FAILs
seen in the libstdc++ testsuite.  As you showed, there is an ABI
change in the library depending on libc version.  Someone needs
to generate a backtrace so that we can get some idea what's happening.

Dave
--
J. David Anglin                                  dave.anglin@...
National Research Council of Canada              [phone] (FAX: [phone])



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

On Sun, Nov 22, 2009 at 10:30:16AM -0500, John David Anglin wrote:

> > > The problem appears to have gone away with head.  I don't see it with
> > > hpux.
> > >
> >
> > Note that latest version of gcc 4.4 in Debian is built with
> > --disable-libstdcxx-pch, but the segfault is this present :(
>
> Personally, I don't believe the segfault is related to the FAILs
> seen in the libstdc++ testsuite.  As you showed, there is an ABI
> change in the library depending on libc version.  Someone needs
> to generate a backtrace so that we can get some idea what's happening.
>

This is what I get using apt-get with the broken libstdc++. Note that
simple hello world programs still works.

| #0  0x4040d8cc in std::locale::operator=(std::locale const&) () from 4.4.2-2/usr/lib/libstdc++.so.6
| #1  0x4040bc10 in std::ios_base::_M_init() () from 4.4.2-2/usr/lib/libstdc++.so.6
| #2  0x40424858 in std::basic_ios<char, std::char_traits<char> >::init(std::basic_streambuf<char, std::char_traits<char> >*) ()
|    from 4.4.2-2/usr/lib/libstdc++.so.6
| #3  0x406ffeec in ReadConfigFile(Configuration&, std::string const&, bool, unsigned int) () from /usr/lib/libapt-pkg-libc6.9-6.so.4.8
| #4  0x406ff9e8 in ReadConfigDir(Configuration&, std::string const&, bool, unsigned int) () from /usr/lib/libapt-pkg-libc6.9-6.so.4.8
| #5  0x4073eeac in pkgInitConfig(Configuration&) () from /usr/lib/libapt-pkg-libc6.9-6.so.4.8
| #6  0x0001d8b8 in main ()

The crash happens at the end of the function:
[...]
| 0x4040d8b8 <_ZNSt6localeaSERKS_+168>:   ldw 0(r5),ret0
| 0x4040d8bc <_ZNSt6localeaSERKS_+172>:   ldw 0(r26),ret0
| 0x4040d8c0 <_ZNSt6localeaSERKS_+176>:   ldo 1(ret0),ret0
| 0x4040d8c4 <_ZNSt6localeaSERKS_+180>:   stw ret0,0(r26)
| 0x4040d8c8 <_ZNSt6localeaSERKS_+184>:   ldw 0(r3),r6
| 0x4040d8cc <_ZNSt6localeaSERKS_+188>:   ldw 0(r6),ret0
| 0x4040d8d0 <_ZNSt6localeaSERKS_+192>:   ldo -1(ret0),r20
| 0x4040d8d4 <_ZNSt6localeaSERKS_+196>:   b,l 0x4040d86c <_ZNSt6localeaSERKS_+92>,r0
| 0x4040d8d8 <_ZNSt6localeaSERKS_+200>:   stw r20,0(r6)
| End of assembler dump.


--
Aurelien Jarno                        GPG: 1024D/F1BCDB73
aurelien@...                 http://www.aurel32.net



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...