Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]

[Florian Weimer <fweimer at redhat dot com>]

On 01/24/2018 07:08 PM, H.J. Lu wrote:
> On Tue, Jan 23, 2018 at 1:13 PM, Senkevich, Andrew
> <andrew.senkevich@intel.com> wrote:
> > > -----Original Message-----
> > > From: Carlos O'Donell [mailto:carlos@redhat.com]
> > > Sent: Tuesday, January 23, 2018 20:35
> > > To: Senkevich, Andrew <andrew.senkevich@intel.com>; H.J. Lu
> > > <hjl.tools@gmail.com>; Florian Weimer <fweimer@redhat.com>; Andreas
> > > Schwab <schwab@suse.de>
> > > Cc: GNU C Library <libc-alpha@sourceware.org>
> > > Subject: Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match
> > > __jmp_buf_tag [BZ #22563]
> > >
> > > On 01/22/2018 06:44 AM, Senkevich, Andrew wrote:
> > > > Looks like that.
> > > > I will have ability to investigate it during tomorrow.
> > >
> > > Any idea what's going wrong?
> >
> > Currently not clear why but I see return from var_AddCallback () (from /usr/lib/x86_64-linux-gnu/libvlccore.so.9) to wrong address.
> > And setjmp/longjmp doesn't break. Will continue tomorrow.
>
> We opened a bug:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=22743
>
> Any help to track down the root cause is appreciated.

Doesn't the bug report clearly show the root cause?  The offset of 
priv.data.cleanup changed, and old binaries have an insufficiently large 
stack allocation for the new offset.

(Congratulations for tracking it down, by the way.  I know that such 
bugs are hard.)

You need to add a symbol version for pthread_register_cancel.  It's too 
late for that now, so I recommend reverting the faulty commit.

Thanks,
Florian