CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9

Brooks Davis brooks at freebsd.org
Thu Jan 17 15:15:03 UTC 2013


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 at gmail.com> wrote:
> > On Wed, Jan 16, 2013 at 6:15 PM, Dimitry Andric <dim at 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 have
> >> 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?
> >
> 
> Confirmed. Reverting world to one commit before r245439 and using the
> version of the port I used before fixes the problem.
> 
> Trying to use the version I compiled with post r245439 world results
> in "su: pam_start: system error" when used on pre r245439 world.
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20130117/eb4cf071/attachment.sig>


More information about the freebsd-stable mailing list