possible bug in structure-type attribute assignement in freeradius-4 alpha

[Stacy]

Hello Alan!

Thanks for help!

I've tried to change configs according to your recommendations.
Here's what I've found - 
the release I've used (the one from the tar image from freeradius.org)
doesn't support structured assignements and asks for missing "&"
symbol. Then, I've switched to the latest master branch from git.

It compiled ok, processed changed configs, but now 
it crashes in a different place, somewhere in 
memory-allocation routines. 

I've suspected, that this is because of incompatible 
version of libtalloc. 
Then I've compiled and installed latest libtalloc (2.4.3)
with developer-features enabled and compiled latest
freeradius master branch against it.

Crashes are still in place.

Here are the logs:

---------------8<----------------8<-----------------------
[.... skipped ....]

(0)    Running 'send Relay-Reply' from file 
/opt/radius_ipv6_dev/etc/raddb/sites-enabled/dhcpv6
(0)    send Relay-Reply {
(0)      reply += {
(0)        Server-ID = {
(0)          DUID = UUID
(0)          UUID = {
(0)            Value = 0x00000000000000000000000000000000
(0)          }
(0)        }
(0)      }
(0)    } # send Relay-Reply ((noop))

Thread 1 "radiusd" received signal SIGSEGV, Segmentation fault.
_talloc_total_mem_internal (ptr=0x16a4e00, type=TOTAL_MEM_LIMIT, old_limit=0x0, new_limit=0x0) at ../../talloc.c:2132
2132                tc->limit->parent == tc) {
(gdb) bt
#0  _talloc_total_mem_internal (ptr=0x16a4e00, type=TOTAL_MEM_LIMIT, old_limit=0x0, new_limit=0x0) at ../../talloc.c:2132
#1  0x00007ffff73ffd86 in _talloc_total_limit_size (ptr=0x16a4e00, old_limit=0x0, new_limit=0x0) at ../../talloc.c:2946
#2  0x00007ffff73fca72 in _talloc_steal_internal (new_ctx=0x7ffff401e590, ptr=0x16a4e00) at ../../talloc.c:1277
#3  0x00007ffff73fcfbe in _talloc_steal_loc (new_ctx=0x7ffff401e590, ptr=0x16a4e00, location=0x7ffff7f8204d "src/lib/util/pair.c:540") at ../../talloc.c:1372
#4  0x00007ffff7ef9e8b in fr_pair_steal (ctx=0x7ffff401e590, vp=0x16a4e00) at src/lib/util/pair.c:540
#5  0x00007ffff7ef9f47 in fr_pair_steal_append (list_ctx=0x7ffff401e590, list=0x7ffff401e5c8, vp=0x16a4e00) at src/lib/util/pair.c:568
#6  0x00007ffff56e836e in restore_field (to_restore=0x16a4d80, request=0x7ffff401e170) at src/process/dhcpv6/base.c:473
#7  resume_send_to_relay (p_result=0x16a23d0, mctx=0x7fffffffddf0, request=0x7ffff401e170) at src/process/dhcpv6/base.c:703
#8  0x00007ffff7bb8400 in unlang_module_resume (p_result=0x16a23d0, request=0x7ffff401e170, frame=0x16a23a0) at src/lib/unlang/module.c:616
#9  0x00007ffff7ba8255 in frame_eval (frame=0x16a23a0, request=0x7ffff401e170) at src/lib/unlang/interpret.c:815
#10 unlang_interpret (request=0x7ffff401e170, running=false) at src/lib/unlang/interpret.c:980
#11 0x00007ffff7b58452 in worker_run_request (start=..., worker=0x1267cc0) at src/lib/io/worker.c:1356
#12 fr_worker_post_event (el=0x136c720, now=..., uctx=0x1267cc0) at src/lib/io/worker.c:1612
#13 0x00007ffff7ed25da in fr_event_service (el=0x136c720) at src/lib/util/event.c:2360
#14 0x00007ffff7ed26c6 in fr_event_loop (el=0x136c720) at src/lib/util/event.c:2400
#15 0x00007ffff7cd7338 in main_loop_start () at src/lib/server/main_loop.c:216
#16 0x00000000004073c1 in main (argc=2, argv=0x7fffffffe4c8) at src/bin/radiusd.c:1000
(gdb) 
(gdb) print *tc
$5 = {flags = 473934632, next = 0x0, prev = 0x16a4eb0, parent = 0x0, child = 0x0, refs = 0x0, destructor = 0x7ffff7ef8ae2 <_fr_pair_free>, 
  name = 0x7ffff7f81d10 "fr_pair_t", size = 176, limit = 0x8, pool = 0x16a21e0}
(gdb) 

----------------8<------------------8<--------------------

Regards,
Stacy