TMPL_TYPE_LITERAL has non-zero bytes in its data union

[Geaaru]

It seems not related to linking. I try to investigate a bit if could be
related to my external module of OCI LIb or other.
Program received signal SIGABRT, Aborted.0x00007ffff6eb86cb in raise ()
from /lib64/libpthread.so.0(gdb) bt#0  0x00007ffff6eb86cb in raise ()
from /lib64/libpthread.so.0#1  0x00007ffff7b43243 in fr_fault (sig=6)
at /home/geaaru/Projects/freeradius-
server/src/lib/debug.c:763#2  0x00007ffff7b43c2a in fr_assert_cond
(file=0x7ffff7dc1cf0 "/home/geaaru/Projects/freeradius-
server/src/main/tmpl.c", line=2155, expr=0x7ffff7dc1df0 "0",
cond=false) at /home/geaaru/Projects/freeradius-
server/src/lib/debug.c:1101#3  0x00007ffff7dac82c in tmpl_verify
(file=0x7ffff7dc01a0 "/home/geaaru/Projects/freeradius-
server/src/main/map.c", line=1529, vpt=0x555555a849f0) at
/home/geaaru/Projects/freeradius-
server/src/main/tmpl.c:2155#4  0x00007ffff7da7598 in map_prints
(buffer=0x7fffffffbd10 "&CHAP-Challenge", bufsize=1023,
map=0x555555a84d60) at /home/geaaru/Projects/freeradius-
server/src/main/map.c:1529#5  0x00007ffff7d9fd82 in fr_cond_sprint
(buffer=0x7fffffffbd10 "&CHAP-Challenge", bufsize=1024,
in=0x555555a845a0) at /home/geaaru/Projects/freeradius-
server/src/main/parser.c:93#6  0x000055555558c5a2 in modcall_debug
(mc=0x555555d622d0, depth=5) at /home/geaaru/Projects/freeradius-
server/src/main/modcall.c:3965#7  0x000055555558c616 in modcall_debug
(mc=0x555555d621d0, depth=4) at /home/geaaru/Projects/freeradius-
server/src/main/modcall.c:3968#8  0x000055555558c616 in modcall_debug
(mc=0x555555d620d0, depth=3) at /home/geaaru/Projects/freeradius-
server/src/main/modcall.c:3968#9  0x000055555558c52f in modcall_debug
(mc=0x555555d61fd0, depth=2) at /home/geaaru/Projects/freeradius-
server/src/main/modcall.c:3958#10 0x0000555555581f87 in
load_component_section (cs=0x555555a76930, components=0x555555d5edb0,
comp=MOD_AUTHORIZE) at /home/geaaru/Projects/freeradius-
server/src/main/modules.c:1241#11 0x00005555555822f3 in load_byserver
(cs=0x555555a765f0) at /home/geaaru/Projects/freeradius-
server/src/main/modules.c:1334#12 0x00005555555828c2 in
virtual_servers_load (config=0x5555557e9690) at
/home/geaaru/Projects/freeradius-server/src/main/modules.c:1521#13
0x0000555555583e7f in modules_init (config=0x5555557e9690) at
/home/geaaru/Projects/freeradius-server/src/main/modules.c:2151#14
0x000055555558d442 in main (argc=8, argv=0x7fffffffd1c8) at
/home/geaaru/Projects/freeradius-server/src/main/radiusd.c:520(gdb)
up#1  0x00007ffff7b43243 in fr_fault (sig=6) at
/home/geaaru/Projects/freeradius-server/src/lib/debug.c:763763		
raise(sig);(gdb) printThe history is empty.(gdb) 
On Fri, 2019-06-21 at 09:56 -0400, Alan DeKok wrote:
> On Jun 21, 2019, at 4:03 AM, Geaaru <geaaru at gmail.com> wrote:
> > in our dev environment now with development version from upstream
> > tree3.0.x I see this error:
> > CONSISTENCY CHECK FAILED src/main/map.c[1529]: TMPL_TYPE_LITERAL
> > hasnon-zero bytes in its data unionSOFT ASSERT FAILED
> > src/main/tmpl.c[2155]: 0CAUGHT SIGNAL: Aborted
> 
>   Weird.
> > Backtrace of last 16 frames:/usr/lib64/libfreeradius-
> > radius.so(fr_fault+0x1a7)[0x7f4f26716637]/usr/lib64/libfreeradius-
> > radius.so(fr_assert_cond+0x50)[0x7f4f26716840]/usr/lib64/libfreerad
> > ius-
> > server.so(tmpl_verify+0x1d0)[0x7f4f26773590]/usr/lib64/libfreeradiu
> > s-
> > server.so(map_prints+0x58)[0x7f4f26770e28]/usr/lib64/libfreeradius-
> > server.so(fr_cond_sprint+0x1a9)[0x7f4f2676f069]/usr/sbin/radiusd(mo
> > dcall_debug+0x27c)[0x55a776bfdffc]/usr/sbin/radiusd(modcall_debug+0
> > xed)[0x55a776bfde6d]
> 
>   Hmm... it would be good to get debugging symbols, i.e. line
> numbers.  That would let us quickly track down & fix the issue.
> > This is an error is related to some issue on linking of the
> > binarybetween mismatched versioning for same libraries or it's
> > related to awrong configuration?
> 
>   It shouldn't be either of those.  Likely something in FreeRADIUS
> isn't initializing things properly at start-up.
> > In Sabayon we have upgraded to glibc-2.29 so I'm not sure if could
> > berelated to some issues of compatibility or whatever.
> 
>   It won't be that.
>   Alan DeKok.