mit-krb-1.4 is using the system libcom_err.so.2 (and the provided compile_et). The compile_et has a broken awk script that makes applications fiddle directly with _et_list so that calls to unregister their error table later makes the program abort with an invalid free (glibc detected invalid pointer in free, blabla). Since libcom_err is already providing a clean handler to add an error table, why does its awk script for client code generation not use it? The attached patches to the com_err ebuild and to /usr/share/et/et_c.awk fix the problem. The problem showed up, for example with - app-crypt/mit_krb5-1.4 - app-crypt/pam_krb5-20030601-r1 with the following system-auth #%PAM-1.0 auth required /lib64/security/pam_env.so auth sufficient /lib64/security/pam_unix.so likeauth nullok broken_shadow auth sufficient /lib64/security/pam_krb5.so use_first_pass auth required /lib64/security/pam_deny.so account sufficient /lib64/security/pam_krb5.so account required /lib64/security/pam_unix.so broken_shadow account required /lib64/security/pam_tally.so deny=5 reset password required /lib64/security/pam_cracklib.so retry=3 password sufficient /lib64/security/pam_krb5.so use_authtok password sufficient /lib64/security/pam_unix.so nullok md5 shadow use_authtok password required /lib64/security/pam_deny.so session required /lib64/security/pam_limits.so session optional /lib64/security/pam_krb5.so session required /lib64/security/pam_unix.so broken_shadow -- After that "su" stops working with the metioned glibc failed assertion abort. Reproducible: Always Steps to Reproduce:
Created attachment 60750 [details, diff] ebuild patch, adds epatch command for the next patch
Created attachment 60751 [details, diff] goes into the ${FILESDIR}
The filename for the second patch for /usr/portage/sys-libs/com_err/files/ should be: com_err-1.37-et_c_awk.patch
Analogous bug report in e2fsprogs bug tracker: http://sourceforge.net/tracker/index.php?func=detail&aid=1150146&group_id=2406&atid=102406
Christophe, what's the latest on this then?
Upstream has acknowledged the problem. My fix is okay in theory, but practically it might introduce other problems (they are worried about binary compatibility with other libcom_err implementations that don't have the dynamic table allocation functions at all). I don't know what's going on exactly at the moment, I'll ask again.
why do we have a stable e2fsprogs port which doesn't compile (without our patch). Can you make a stable e2fsprogs ebuild for that? Thanks, Martin PS. I hope to see a stable one the next days...
Upstream has resolved the problems in e2fsprogs-1.38. A workaround for programs compiled with the old compile_et as well as an improved compile_et.
great, thanks i added 1.38 yesterday so ... :)
*** Bug 98303 has been marked as a duplicate of this bug. ***
Any chance to change from "~alpha" to "alpha"? I just built it and there are no obvious problems.
