Pre-release of Version 2.1.8

[Alan DeKok]

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.