Alexander Clouter wrote: > Not quite on the pre-release but running > f691b0ec7d4c92919bdd4dc81e8a86b211c00832 from the stable branch I got > these after a 'hiccup' this morning on the network: > ---- > Program received signal SIGPIPE, Broken pipe. > [Switching to Thread 0x411b9950 (LWP 18045)] > 0x00007fa8a156b75b in write () from /lib/libpthread.so.0 > (gdb) bt > #0 0x00007fa8a156b75b in write () from /lib/libpthread.so.0 > #1 0x00007fa89e51c1a9 in ?? () from /usr/lib/liblber-2.4.so.2 > #2 0x00007fa89e06f4b9 in _gnutls_io_write_buffered () from > /usr/lib/libgnutls.so.26
Ugh. > Then shortly after restarting it: > ---- > Program received signal SIGABRT, Aborted. > [Switching to Thread 0x4f492950 (LWP 23808)] > 0x00007f0060554ed5 in raise () from /lib/libc.so.6 > (gdb) wher > #0 0x00007f0060554ed5 in raise () from /lib/libc.so.6 > #1 0x00007f00605563f3 in abort () from /lib/libc.so.6 > #2 0x00000000004281f2 in rad_assert_fail (file=0x4455ef "threads.c", > line=406, > expr=0x445628 "(*request)->magic == REQUEST_MAGIC") at util.c:363 > #3 0x0000000000426adf in request_dequeue (request=0x7f004c006f30, > fun=0x4f491d30) at threads.c:406 That shouldn't happen... ever! In fact, I've never seen it happen. It can occur only when memory is free'd, and still used. > The former one I have seen before and assuemd it was a bug in libldap, > however I guess maybe freeradius should be catching the SIGPIPE there? Nope. The libraries usually re-set the signal handlers. > As for the latter one, that's new to me. Alas it is going to be > difficult to repeat this 'experiment' as I would have to turn power off > to one of our server rooms...tends to annoy the yokels. It should either happen a lot, or not at all. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html