Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9
--DO5DiztRLs659m5i
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Jan 17, 2013 at 09:06:27AM +0200, Kimmo Paasiala wrote:
> On Wed, Jan 16, 2013 at 8:01 PM, Kimmo Paasiala <kpaasial@gmail.com> wrot=
e:
> > On Wed, Jan 16, 2013 at 6:15 PM, Dimitry Andric <dim@freebsd.org> wrote:
> >> On 2013-01-16 13:05, Kimmo Paasiala wrote:
> >>>
> >>> I just updated my stable/9 system after clang3.2 was added. My system
> >>> is amd64, both world and kernel are compiled with clang3.2 and the
> >>> default compiler is clang. I'm tracking the sources with GIT and the
> >>> version I have corresponds to SVN revision r245451.
> >>>
> >>> Everything else seems to work but the pam authentication module
> >>> security/pam_ssh_agent_auth segfaults immediately.
> >>
> >> ...
> >>
> >>> #0 0x0000000800ef2070 in strsvis () from /lib/libc.so.7
> >>> #1 0x0000000800ef2584 in strvis () from /lib/libc.so.7
> >>> #2 0x0000000800ef25e5 in strnvis () from /lib/libc.so.7
> >>> #3 0x0000000801c0e2e7 in do_log () from
> >>> /usr/local/lib/pam_ssh_agent_auth.so
> >>> #4 0x0000000801c0e4ff in logit () from
> >>> /usr/local/lib/pam_ssh_agent_auth.so
> >>
> >> ...
> >>
> >>> The str*vis() calls suggest that it's something in the libc maybe?
> >>
> >>
> >> Brooks merged the new strvis implementations in r245439, so you may ha=
ve
> >> run into a bug with them. I don't think this is caused specifically by
> >> clang, at least not without more proof. :-)
> >>
> >> Can you try reverting to the revision just before r245439, rebuilding
> >> and reinstalling at least libc, and see if the pam_ssh_agent_auth crash
> >> goes away?
> >
>=20
> Confirmed. Reverting world to one commit before r245439 and using the
> version of the port I used before fixes the problem.
>=20
> Trying to use the version I compiled with post r245439 world results
> in "su: pam_start: system error" when used on pre r245439 world.
>=20
> I have to repeat my question, isn't this the definition of ABI breakage?
Not unless you consider adding new functions in a reserved namespace
(str*) to be ABI breakage. The port should have continued to work unless
it was recompiled so it should have preferred it's own version of the
strnvis symbol. If it's makefiles were properly constructed it would
have failed to compile due to the signature mismatch. It's unfortunate
that NetBSD and OpenBSD picked different function signatures for
strnvis, but it's beyond our control.
-- Brooks
--DO5DiztRLs659m5i
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
iD8DBQFQ+BV1XY6L6fI4GtQRAtaNAJsHQVYaNHXInS03N8GxQm0bWn8rVQCfSIhe
dKJoNP/cECoGA7vD5z4B70U=
=Hy/2
-----END PGP SIGNATURE-----
--DO5DiztRLs659m5i--
討論串 (同標題文章)
完整討論串 (本文為第 12 之 27 篇)：