Solved ssh-keygen segfaulting after 9.3-RELEASE-p33 upgrade

After upgrading my FreeBSD 9.3 server to 9.3-RELEASE-p33, I noticed that I could no longer SSH into the server. When I tried regenerating the host keys, the DSA host key won't regenerate, and the following message shows up in /var/log/messages:

...kernel: pid 1245 (ssh-keygen), uid 0: exited on signal 11 (core dumped)

When I run ssh-keygen -A, I see:

ssh-keygen: generating new host keys: DSA Segmentation fault (core dumped)

/usr/bin/ssh-keygen was definitely part of today's updates:

% ls -l /usr/bin/ssh-keygen
-r-x-r-xr-x  1 root  wheel  57824 Mar  8 12:27 /usr/bin/ssh-keygen

In case this was due to an incomplete upgrade from FreeBSD 9.2 last year, I tried reinstalling the OS using the 9.3 ISO and installing updates afterward. After those updates, SSH access was again broken with DSA key regeneration segfaulting.

Has anyone else run into this issue? Any ideas on how to fix it other than reinstalling 9.3 (since that does not work)? I suppose I could just install FreeBSD 10.1 because I have not run into this issue with those updates, which I just performed on some 10.1 hosts last week at the latest. I haven't performed any updates on any of my 9.3 hosts this year until today.
I had problems as well after applying p37 security updates to 9.3-RELEASE. I happened to be watching the maillog after the update and noticed postfix and dovecot throwing a fit. Rebooted and was unable to SSH. HTTPS and anything encryption related was broken. After a few minutes of panic, I did a rollback and all is well again. My plan at this point is to wait a few days and try again.
Yeah, my server is on an ESXi VM so I had a snapshot to which I could restore, fortunately.

This is the first time that a FreeBSD update has broken something for me. I can't really say I'm disappointed because even Windows has bad updates, not to mention that it seems to have them more frequently than FreeBSD or any other *nix-based OS I've used in the past.

I suppose I'll just wait, too. : - )
Sounds like the same issues I have been seeing. This is probably the correct PR: PR 207783. Looks like something's buggered up in /lib/ after the last update.