TMPL_TYPE_LITERAL has non-zero bytes in its data union

[Geaaru]

I try to share debug symbols Tuesday or Wednesday. This Monday is a
holiday day here.
Thanks
g.

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.