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

[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-hppa-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-hppa-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-hppa-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-hppa-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-hppa-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-hppa-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-hppa-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-hppa-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-hppa-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-hppa-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-hppa-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-hppa-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-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Sun, Nov 22, 2009 at 10:30 AM, John David Anglin
<dave@...> 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.

Running apt-get with the newly compiled libstdc++6 with
--without-cloog/--without-ppl still cause the segfault.

The glibc locale() function is causing this failure.

The segfault happens when basic_ios is being initialized. The
ios_base::_M_init() calls locale() to create a locale object and
stores this into _M_ios_locale. The assignment is done through an
operator= for the locale type, and this crashes.

Starting program: /usr/bin/apt-get

Program received signal SIGSEGV, Segmentation fault.
std::locale::operator= (this=0xbff01c84, __other=...) at
../../../../src/libstdc++-v3/src/locale.cc:116
116         _M_impl->_M_remove_reference();
Current language:  auto; currently c++
(gdb) bt
#0  std::locale::operator= (this=0xbff01c84, __other=...) at
../../../../src/libstdc++-v3/src/locale.cc:116
#1  0x40390c10 in std::ios_base::_M_init (this=0xbff01fc8) at
../../../../src/libstdc++-v3/src/ios_locale.cc:43
#2  0x403a9858 in std::basic_ios<char, std::char_traits<char> >::init
(this=0x4043e890, __sb=0xbff01fc8)
    at /home/carlos/fsrc/debian/gcc-4.4-4.4.2/build/hppa-linux-gnu/libstdc++-v3/include/bits/basic_ios.tcc:128
#3  0x405c7eec in ReadConfigFile(Configuration&, std::string const&,
bool, unsigned int) () from /usr/lib/libapt-pkg-libc6.9-6.so.4.8
#4  0x405c79e8 in ReadConfigDir(Configuration&, std::string const&,
bool, unsigned int) () from /usr/lib/libapt-pkg-libc6.9-6.so.4.8
#5  0x40606eac in pkgInitConfig(Configuration&) () from
/usr/lib/libapt-pkg-libc6.9-6.so.4.8
#6  0x0001d8b8 in main ()
(gdb)

This is the 14th call to std::locale::operator=, but the first call
with an object that was created on the stack.

The object *this a std::locale object, has an invalid _M_impl member,
whose value should be a pointer to an implementation but instead it's
a value of 0x8.

This happens because the original locale object was created at address
0xbff01c20. However, when apt-get calls "std::basic_ios<char,
std::char_traits<char> >::init" it passes in the address 0xbff01c18.
So we went from a constructor using this as 0xbff01c20, to eventually
passing this as 0xbff01c18 to a template. The pointer to the
std::ios_base object is now off by 8 bytes and this causes the crash.

What happened here? Why does ReadConfigFile() think that the object is
in a different location?

Any hints on how to track this down?

Cheers,
Carlos.


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

[Carlos O'Donell-2]

On Sun, Nov 22, 2009 at 2:51 PM, Carlos O'Donell
<carlos@...> wrote:

> This happens because the original locale object was created at address
> 0xbff01c20. However, when apt-get calls "std::basic_ios<char,
> std::char_traits<char> >::init" it passes in the address 0xbff01c18.
> So we went from a constructor using this as 0xbff01c20, to eventually
> passing this as 0xbff01c18 to a template. The pointer to the
> std::ios_base object is now off by 8 bytes and this causes the crash.
>
> What happened here? Why does ReadConfigFile() think that the object is
> in a different location?
>
> Any hints on how to track this down?

The problem is here, we read 0xa8 here from libstdc++6:

(gdb) x/16x $ret0 - 0xc
0x40437778 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si>:
0x000000a8      0x00000000      0x40437b30      0x401b2b96
0x40437788 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+16>:
 0x401b2b9e      0xffffff58      0xffffff58      0x40437b30
0x40437798 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+32>:
 0x401b2ba6      0x401b2bae      0x00000000      0x40437834

Then we add this offset to the base location of the object on the
stack and we compute 0xbff01c18, instead of computing 0xbff01c20 as we
would expect.

It looks like the layout of the object in libstdc++.so.6 has changed,
my guess is that the changes I made to the locking types in glibc have
caused the layout to be perturbed.

While I set out the glibc types exactly as before (binary compatible),
the alignment restrictions were changed subtly.

I will go back immediately and review this.

Cheers,
Carlos.


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

[John David Anglin-4]

>
> On Sun, Nov 22, 2009 at 2:51 PM, Carlos O'Donell
> <carlos@...> wrote:
> > This happens because the original locale object was created at address
> > 0xbff01c20. However, when apt-get calls "std::basic_ios<char,
> > std::char_traits<char> >::init" it passes in the address 0xbff01c18.
> > So we went from a constructor using this as 0xbff01c20, to eventually
> > passing this as 0xbff01c18 to a template. The pointer to the
> > std::ios_base object is now off by 8 bytes and this causes the crash.
> >
> > What happened here? Why does ReadConfigFile() think that the object is
> > in a different location?
> >
> > Any hints on how to track this down?

The ptype command might help to display the object and to see what's
changed.

> The problem is here, we read 0xa8 here from libstdc++6:
>
> (gdb) x/16x $ret0 - 0xc
> 0x40437778 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si>:
> 0x000000a8      0x00000000      0x40437b30      0x401b2b96
> 0x40437788 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+16>:
>  0x401b2b9e      0xffffff58      0xffffff58      0x40437b30
> 0x40437798 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+32>:
>  0x401b2ba6      0x401b2bae      0x00000000      0x40437834
>
> Then we add this offset to the base location of the object on the
> stack and we compute 0xbff01c18, instead of computing 0xbff01c20 as we
> would expect.
>
> It looks like the layout of the object in libstdc++.so.6 has changed,
> my guess is that the changes I made to the locking types in glibc have
> caused the layout to be perturbed.
>
> While I set out the glibc types exactly as before (binary compatible),
> the alignment restrictions were changed subtly.

Excellent debugging!

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


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

[Carlos O'Donell-2]

On Sun, Nov 22, 2009 at 5:05 PM, John David Anglin
<dave@...> wrote:
>> While I set out the glibc types exactly as before (binary compatible),
>> the alignment restrictions were changed subtly.
>
> Excellent debugging!

I have adjusted the glibc lock structure alignments to try and match
more accurately the original alignment restrictions.

I have built a glibc with the new headers, and installed that into my
test system.

I'm now rebuilding libstdc++6 against the new headers to determine if
this fixes the problem.

I will have results by tomorrow.

Cheers,
Carlos.


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

[Aurelien Jarno]

Carlos O'Donell a écrit :

> On Sun, Nov 22, 2009 at 5:05 PM, John David Anglin
> <dave@...> wrote:
>>> While I set out the glibc types exactly as before (binary compatible),
>>> the alignment restrictions were changed subtly.
>> Excellent debugging!
>
> I have adjusted the glibc lock structure alignments to try and match
> more accurately the original alignment restrictions.
>
> I have built a glibc with the new headers, and installed that into my
> test system.
>
> I'm now rebuilding libstdc++6 against the new headers to determine if
> this fixes the problem.
>
> I will have results by tomorrow.
>

Thanks a lot for the investigation, I really hope this will work.

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


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

[Carlos O'Donell-2]

On Mon, Nov 23, 2009 at 5:22 AM, Aurelien Jarno <aurelien@...> wrote:

> Carlos O'Donell a écrit :
>> On Sun, Nov 22, 2009 at 5:05 PM, John David Anglin
>> <dave@...> wrote:
>>>> While I set out the glibc types exactly as before (binary compatible),
>>>> the alignment restrictions were changed subtly.
>>> Excellent debugging!
>>
>> I have adjusted the glibc lock structure alignments to try and match
>> more accurately the original alignment restrictions.
>>
>> I have built a glibc with the new headers, and installed that into my
>> test system.
>>
>> I'm now rebuilding libstdc++6 against the new headers to determine if
>> this fixes the problem.
>>
>> I will have results by tomorrow.
>>
>
> Thanks a lot for the investigation, I really hope this will work.

It worked. I now see 0xb0 as the object offset, which gives a
compatible object layout for the libstdc++ iostream classes.

(gdb) x/16x $ret0 - 0xc
0x409a6f38 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si>:
0x000000b0      0x00000000      0x409a72f0      0x401b2b96
0x409a6f48 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+16>:
 0x401b2b9e      0xffffff50      0xffffff50      0x409a72f0
0x409a6f58 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+32>:
 0x401b2ba6      0x401b2bae      0x00000000      0x409a6ff4
0x409a6f68 <_ZTVSt13basic_filebufIcSt11char_traitsIcEE+8>:
0x401b2e6e      0x401b2e76      0x401b2e7e      0x401b2e86

I can successfully run apt-get with the new libstdc++6 that I just built.

The testsuite result is cleaner:
~~~
FAIL: 29_atomics/atomic_flag/clear/1.c execution test
FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test

                === libstdc++ Summary ===

# of expected passes            5880
# of unexpected failures        2
# of expected failures          80
# of unsupported tests          331
~~~

I am still building with
~~~
# Disable cloog/ppl and pch on hppa.
ifneq (,$(findstring $(DEB_TARGET_ARCH), hppa))
  CONFARGS += --without-ppl --without-cloog --disable-libstdcxx-pch
endif
~~~
However, I don't think this made any difference.

Next steps:
(1) Wait for testsuite results to finish completely. Verify nothing
has regressed.
(2) Remove changes to gcc package debian/rules2 and re-run validation.
(3) In parallel provide new patch to debian-glibc to fix alignment
issues with pthread types.
(4) Ask debian-glibc team to run a build and look for testsuite regressions.

If the test results for (2) and (4) are clean, then I will give the
green light for a new glibc to be uploaded. This will fix the
libstdc++6 issues.

Cheers,
Carlos.


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

[Aurelien Jarno]

On Mon, Nov 23, 2009 at 08:17:03AM -0500, Carlos O'Donell wrote:

> On Mon, Nov 23, 2009 at 5:22 AM, Aurelien Jarno <aurelien@...> wrote:
> > Carlos O'Donell a écrit :
> >> On Sun, Nov 22, 2009 at 5:05 PM, John David Anglin
> >> <dave@...> wrote:
> >>>> While I set out the glibc types exactly as before (binary compatible),
> >>>> the alignment restrictions were changed subtly.
> >>> Excellent debugging!
> >>
> >> I have adjusted the glibc lock structure alignments to try and match
> >> more accurately the original alignment restrictions.
> >>
> >> I have built a glibc with the new headers, and installed that into my
> >> test system.
> >>
> >> I'm now rebuilding libstdc++6 against the new headers to determine if
> >> this fixes the problem.
> >>
> >> I will have results by tomorrow.
> >>
> >
> > Thanks a lot for the investigation, I really hope this will work.
>
> It worked. I now see 0xb0 as the object offset, which gives a
> compatible object layout for the libstdc++ iostream classes.
>
> (gdb) x/16x $ret0 - 0xc
> 0x409a6f38 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si>:
> 0x000000b0      0x00000000      0x409a72f0      0x401b2b96
> 0x409a6f48 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+16>:
>  0x401b2b9e      0xffffff50      0xffffff50      0x409a72f0
> 0x409a6f58 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+32>:
>  0x401b2ba6      0x401b2bae      0x00000000      0x409a6ff4
> 0x409a6f68 <_ZTVSt13basic_filebufIcSt11char_traitsIcEE+8>:
> 0x401b2e6e      0x401b2e76      0x401b2e7e      0x401b2e86
>
> I can successfully run apt-get with the new libstdc++6 that I just built.

Nice work :)

> The testsuite result is cleaner:
> ~~~
> FAIL: 29_atomics/atomic_flag/clear/1.c execution test
> FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test
>
>                 === libstdc++ Summary ===
>
> # of expected passes            5880
> # of unexpected failures        2
> # of expected failures          80
> # of unsupported tests          331
> ~~~
>
> I am still building with
> ~~~
> # Disable cloog/ppl and pch on hppa.
> ifneq (,$(findstring $(DEB_TARGET_ARCH), hppa))
>   CONFARGS += --without-ppl --without-cloog --disable-libstdcxx-pch
> endif
> ~~~
> However, I don't think this made any difference.
>
> Next steps:
> (1) Wait for testsuite results to finish completely. Verify nothing
> has regressed.
> (2) Remove changes to gcc package debian/rules2 and re-run validation.
> (3) In parallel provide new patch to debian-glibc to fix alignment
> issues with pthread types.
> (4) Ask debian-glibc team to run a build and look for testsuite regressions.
>
> If the test results for (2) and (4) are clean, then I will give the
> green light for a new glibc to be uploaded. This will fix the
> libstdc++6 issues.

I guess there is a fifth step need:
(5) rebuild gcc-4.4 against the fixed glibc.

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


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