[tpop3d-discuss] PAM Problem (FreeBSD)

[Ben Schumacher]

On Wed, 31 Jul 2002, Odhiambo Washington wrote:
> Okay - decide ;-)
>
> [tpop3d, version 1.4.1]
>
>
> wash@ns2 ('tty') ~ 876 -> sudo gdb /usr/local/sbin/tpop3d /tpop3d.core
> GNU gdb 4.18 (FreeBSD)
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)...
> Core was generated by `tpop3d'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done.
> Reading symbols from /usr/lib/libwrap.so.3...(no debugging symbols found)...done.
> Reading symbols from /usr/local/lib/libmysqlclient.so.10...(no debugging symbols found)...done.
> Reading symbols from /usr/lib/libpam.so.1...(no debugging symbols found)...done.
> Reading symbols from /usr/lib/libcrypt.so.2...(no debugging symbols found)...done.
> Reading symbols from /usr/lib/libc.so.4...(no debugging symbols found)...done.
> Reading symbols from /usr/lib/libz.so.2...(no debugging symbols found)...done.
> Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done.
> #0  0x2814a41a in vfprintf () from /usr/lib/libc.so.4
> (gdb) bt
> #0  0x2814a41a in vfprintf () from /usr/lib/libc.so.4
> #1  0x28114dbe in vsnprintf () from /usr/lib/libc.so.4
> #2  0x804e6ed in sigprocmask ()
> #3  0x804e71a in sigprocmask ()
> #4  0x80510d9 in sigprocmask ()
> #5  0x804a0b5 in sigprocmask ()
> (gdb) quit

Your crash occurred in the standard C libraries, which don't have
debugging symbols on your system [Reading symbols from
/usr/lib/libc.so.4...(no debugging symbols found)...done.], so nothing
useful can really be cleaned from this core. If you went back into gdb and
did 'up' a fair number of times, you might be able to trace back to the
place in tpop3d where the system call that eventually cause the crash
happened, but you probably still wouldn't be able to find out anything all
that useful.

I'd chalk this up to a library inconsistency caused during the upgrade.
You might want to recompile (I know I'm reneging on my previous comment),
but you could probably just bit-bucket the core, as it isn't all that
useful. (Unless Chris has some objections. ;)

bs.