On 10/03/2016 12:20 PM, Alan DeKok wrote:
On Oct 3, 2016, at 3:02 PM, Mike Ely <me@mikeely.org> wrote:
(gdb) p *realm->acct_pool $2 = {name = 0x7f48e63e5f30 "daffy.net", type = HOME_POOL_FAIL_OVER, server_type = 2, cs = 0x7f48e63e5dc0, virtual_server = 0x0, fallback = 0x0, in_fallback = 0, time_all_dead = 0, num_home_servers = 3, servers = { 0x7f48e64718d0}} (gdb) p *realm->acct_pool->servers $3 = (home_server_t *) 0x7f48e64718d0
And one last one...
(gdb) p i
My guess is that this will print "3", or "4".
It looks like something completely catastrophic is happening. The pool is *supposed* to have 3 servers. But for some reason, the array entry is NULL, *or* the code is walking off of the end of the array somehow.
That shouldn't happen. i.e. it's a catastrophic error that signals something completely bizarre is going on. I've never seen this before.
So I'm recompiling these packages on the atom with the "right" CPU optimizations and will report success or failure once I know. In the meantime I figured out the triggering condition: The third and final authhost for "daffy.net" is down. When that server gets tried, the segfault occurs. Which is at least nice in that I can now trigger the problem at will. Like I say, I'll let you know when I have answered whether the issue is fixed by different compile options.