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.