Summary: | Infinite loop in com_err-1.38. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Fredrik Tolf <fredrik> |
Component: | [OLD] Library | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED WORKSFORME | ||
Severity: | major | CC: | kerberos |
Priority: | High | ||
Version: | 2005.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Fredrik Tolf
2005-08-05 13:43:38 UTC
I have re-emerged com_err with FEATURES="noclean nostrip" and CFLAGS="-g", and I've managed to get some more debugging info from an ipop3d process that died from this. Apparently, the initial debugging info was, as I suspected, wrong, and the loop is taking place in error_message.c rather than "auth.c" (whatever that came from). The actual loop in question is the one from lines 57 to 65 in that file: for (et = _et_list; et; et = et->next) { if (et->table->base == table_num) { /* This is the right table */ if (et->table->n_msgs <= offset) goto oops; return(et->table->msgs[offset]); } } Apparently, the first element of the _et_list points to itself: (gdb) p _et_list $5 = (struct et_list *) 0xb7ba1bc8 (gdb) p *_et_list $6 = {next = 0xb7ba1bc8, table = 0xb7b9c8c4} In other words, _et_list and _et_list->next both point to the same address, which, of course, helps explain why this occurs. That's all I have for now. Hopefully I'll be able to find out how this happened _et_list in the first place. i think ive seen mention of this before ... could you try contacting the upstream author please ? tytso@alum.mit.edu For unknown reasons, this doesn't happen for me anymore. Maybe upstream fixed it? dunno ... there have been fixes incorporated which bring com_err up to speed with the version used in mit-krb |