Segfaults in MIT libkrb5

[Theodore Tso]

On Mon, Dec 18, 2006 at 11:47:47PM +0100, Fredrik Tolf wrote:
> Then again, working around bugs in dynlinkers isn't really Kerberos'
> job, is it? If people are running systems with buggy dynlinkers,
> shouldn't they expect related bugs in programs that use dynamic linking?

Well, obviously it depends on the bug.  What I'm wondering about here
is whether for some reason the destructor is not getting called at
all, or if because you the dynamic loader somehow managed to load two
copies of the same library into memory (instead of simply using the
krb5 library you already had linked against your program), and then
these calls in the destructor are somehow using the wrong version of
et_*_error_table:

    remove_error_table(&et_krb5_error_table);
    remove_error_table(&et_kv5m_error_table);
    remove_error_table(&et_kdb5_error_table);
    remove_error_table(&et_asn1_error_table);
    remove_error_table(&et_k524_error_table);

This could cause the wrong version of the error tables to be removed
from the linked list, causing a crash when the krb5 library is
unmapped.

> Is it really necessary to patch libcom_err? Can't I just attach gdb to
> it and have it break on remove_error_table?

Well, you could have gdb break on add_remove_table and
remove_error_table, and then track the name of the error table and the
address, manually, sure.  I happen to think that patching libcom_err,
is actually less work than manually transcribing the necessary
information, but maybe that's because as the e2fsprogs maintainer I'm
always rebuilding and reinstalling the e2fsprogs libraries as a matter
of course.  The manual gdb approach can be quite a bit more of a
bother, and error prone, and more than once I've gone down blind
alleys when I goofed while grabbing debugging information from gdb,
and ended up wasting huge amounts of time based on a botched
observation.  So I have a personal bias towards adding robust
debugging framework as opposed to depending on manual gdb efforts.

					- Ted