Signal handling broken on alpha since glibc-2.16

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Signal handling broken on alpha since glibc-2.16

Matt Turner-3
A test from the gcc test suite shows that signal handling is broken on
alpha since glibc-2.16. Bisecting before the glibc-ports merge is
rather hard.

See: https://bugs.gentoo.org/show_bug.cgi?id=480740 (includes test case)

Off hand, do any changes between 2.15 and 2.16 seem to be likely
candidates to cause this bug?

Thanks,
Matt
Reply | Threaded
Open this post in threaded view
|

Re: Signal handling broken on alpha since glibc-2.16

Richard Henderson
On 11/04/2013 11:10 AM, Matt Turner wrote:
> A test from the gcc test suite shows that signal handling is broken on
> alpha since glibc-2.16. Bisecting before the glibc-ports merge is
> rather hard.
>
> See: https://bugs.gentoo.org/show_bug.cgi?id=480740 (includes test case)
>
> Off hand, do any changes between 2.15 and 2.16 seem to be likely
> candidates to cause this bug?

It's likely to be change 7d1feb5693be7e606104cc2b6657c746a93e5926.

Please try this.


r~

zz (852 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Signal handling broken on alpha since glibc-2.16

Matt Turner-3
On Wed, Nov 13, 2013 at 2:50 PM, Richard Henderson <[hidden email]> wrote:

> On 11/04/2013 11:10 AM, Matt Turner wrote:
>> A test from the gcc test suite shows that signal handling is broken on
>> alpha since glibc-2.16. Bisecting before the glibc-ports merge is
>> rather hard.
>>
>> See: https://bugs.gentoo.org/show_bug.cgi?id=480740 (includes test case)
>>
>> Off hand, do any changes between 2.15 and 2.16 seem to be likely
>> candidates to cause this bug?
>
> It's likely to be change 7d1feb5693be7e606104cc2b6657c746a93e5926.
>
> Please try this.

Looks like it works here. Thanks!

RA = 0x120000c44, CFA = 0x11fc9e800
RA = 0x120000c78, CFA = 0x11fc9e810
RA = 0x200000b49d0, CFA = 0x11fc9e820
RA = 0x120000aac, CFA = 0x11fc9eb58
RA = 0x120000b38, CFA = 0x11fc9eb90
RA = 0x120000b58, CFA = 0x11fc9ec30
RA = 0x1200008e8, CFA = 0x11fc9ec40
RA = 0x2000009ad00, CFA = 0x11fc9ec50
Aborted
Reply | Threaded
Open this post in threaded view
|

Re: Signal handling broken on alpha since glibc-2.16

Uros Bizjak-3
On Thu, Nov 14, 2013 at 3:18 AM, Matt Turner <[hidden email]> wrote:

> On Wed, Nov 13, 2013 at 2:50 PM, Richard Henderson <[hidden email]> wrote:
>> On 11/04/2013 11:10 AM, Matt Turner wrote:
>>> A test from the gcc test suite shows that signal handling is broken on
>>> alpha since glibc-2.16. Bisecting before the glibc-ports merge is
>>> rather hard.
>>>
>>> See: https://bugs.gentoo.org/show_bug.cgi?id=480740 (includes test case)
>>>
>>> Off hand, do any changes between 2.15 and 2.16 seem to be likely
>>> candidates to cause this bug?
>>
>> It's likely to be change 7d1feb5693be7e606104cc2b6657c746a93e5926.
>>
>> Please try this.
>
> Looks like it works here. Thanks!
>
> RA = 0x120000c44, CFA = 0x11fc9e800
> RA = 0x120000c78, CFA = 0x11fc9e810
> RA = 0x200000b49d0, CFA = 0x11fc9e820
> RA = 0x120000aac, CFA = 0x11fc9eb58
> RA = 0x120000b38, CFA = 0x11fc9eb90
> RA = 0x120000b58, CFA = 0x11fc9ec30
> RA = 0x1200008e8, CFA = 0x11fc9ec40
> RA = 0x2000009ad00, CFA = 0x11fc9ec50
> Aborted

The test should not abort. Did you compiled it with -fexceptions
-fnon-call-exceptions?

Uros.
Reply | Threaded
Open this post in threaded view
|

Re: Signal handling broken on alpha since glibc-2.16

Matt Turner-3
On Wed, Nov 13, 2013 at 11:27 PM, Uros Bizjak <[hidden email]> wrote:

> On Thu, Nov 14, 2013 at 3:18 AM, Matt Turner <[hidden email]> wrote:
>> On Wed, Nov 13, 2013 at 2:50 PM, Richard Henderson <[hidden email]> wrote:
>>> On 11/04/2013 11:10 AM, Matt Turner wrote:
>>>> A test from the gcc test suite shows that signal handling is broken on
>>>> alpha since glibc-2.16. Bisecting before the glibc-ports merge is
>>>> rather hard.
>>>>
>>>> See: https://bugs.gentoo.org/show_bug.cgi?id=480740 (includes test case)
>>>>
>>>> Off hand, do any changes between 2.15 and 2.16 seem to be likely
>>>> candidates to cause this bug?
>>>
>>> It's likely to be change 7d1feb5693be7e606104cc2b6657c746a93e5926.
>>>
>>> Please try this.
>>
>> Looks like it works here. Thanks!
>>
>> RA = 0x120000c44, CFA = 0x11fc9e800
>> RA = 0x120000c78, CFA = 0x11fc9e810
>> RA = 0x200000b49d0, CFA = 0x11fc9e820
>> RA = 0x120000aac, CFA = 0x11fc9eb58
>> RA = 0x120000b38, CFA = 0x11fc9eb90
>> RA = 0x120000b58, CFA = 0x11fc9ec30
>> RA = 0x1200008e8, CFA = 0x11fc9ec40
>> RA = 0x2000009ad00, CFA = 0x11fc9ec50
>> Aborted
>
> The test should not abort. Did you compiled it with -fexceptions
> -fnon-call-exceptions?

Whoops. Compiling with the proper CFLAGS leads to better results:

RA = 0x120000bdc, CFA = 0x11f8f8f00
RA = 0x120000c14, CFA = 0x11f8f8f00
RA = 0x120000c38, CFA = 0x11f8f8f10
RA = 0x120000c5c, CFA = 0x11f8f8f10
RA = 0x2000009e9d0, CFA = 0x11f8f8f20
RA = 0x120000aec, CFA = 0x11f8f9258
RA = 0x120000b84, CFA = 0x11f8f9280
RA = 0x120000d28, CFA = 0x11f8f9320

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Signal handling broken on alpha since glibc-2.16

Uros Bizjak-3
On Thu, Nov 14, 2013 at 5:43 PM, Matt Turner <[hidden email]> wrote:

>>>>> A test from the gcc test suite shows that signal handling is broken on
>>>>> alpha since glibc-2.16. Bisecting before the glibc-ports merge is
>>>>> rather hard.
>>>>>
>>>>> See: https://bugs.gentoo.org/show_bug.cgi?id=480740 (includes test case)
>>>>>
>>>>> Off hand, do any changes between 2.15 and 2.16 seem to be likely
>>>>> candidates to cause this bug?
>>>>
>>>> It's likely to be change 7d1feb5693be7e606104cc2b6657c746a93e5926.
>>>>
>>>> Please try this.
>>>
>>> Looks like it works here. Thanks!
>>>
>>> RA = 0x120000c44, CFA = 0x11fc9e800
>>> RA = 0x120000c78, CFA = 0x11fc9e810
>>> RA = 0x200000b49d0, CFA = 0x11fc9e820
>>> RA = 0x120000aac, CFA = 0x11fc9eb58
>>> RA = 0x120000b38, CFA = 0x11fc9eb90
>>> RA = 0x120000b58, CFA = 0x11fc9ec30
>>> RA = 0x1200008e8, CFA = 0x11fc9ec40
>>> RA = 0x2000009ad00, CFA = 0x11fc9ec50
>>> Aborted
>>
>> The test should not abort. Did you compiled it with -fexceptions
>> -fnon-call-exceptions?
>
> Whoops. Compiling with the proper CFLAGS leads to better results:
>
> RA = 0x120000bdc, CFA = 0x11f8f8f00
> RA = 0x120000c14, CFA = 0x11f8f8f00
> RA = 0x120000c38, CFA = 0x11f8f8f10
> RA = 0x120000c5c, CFA = 0x11f8f8f10
> RA = 0x2000009e9d0, CFA = 0x11f8f8f20
> RA = 0x120000aec, CFA = 0x11f8f9258
> RA = 0x120000b84, CFA = 0x11f8f9280
> RA = 0x120000d28, CFA = 0x11f8f9320

Yes, this is the correct sequence (the signal frame is the 5th frame),
and we are able to unwind through the signal frame again.

Thanks,
Uros.