TMPL_TYPE_LITERAL has non-zero bytes in its data union

[Geaaru]

Hi Jorge,
all data (or at least how reproduce it) are available in the previous
post in ML: 
- 
http://lists.freeradius.org/pipermail/freeradius-devel/2019-June/013544.html
- 
http://lists.freeradius.org/pipermail/freeradius-devel/2019-June/013554.html
Alan, like me after some emails he clean mail thread :)
Bye
On Fri, 2019-07-05 at 14:36 -0300, Jorge Pereira wrote:
> Please,
> Share the radius -XXx output. And If you are getting some crash,
> please share the stack trace as you got previously.—Jorge Pereira
> 
> 
> 
> > On 5 Jul 2019, at 14:34, Geaaru <geaaru at gmail.com> wrote:
> > Hi,I had investigate a bit on this and it's very weird.I revert the
> > code of the tag 3.0.17 that is now in production and wherecode with
> > PAP/CHAP condition works perfectly, but now with the same3.0.17 in
> > upgraded rootfs I receive the same error.I fear that could be
> > related to some library used by Freeradius.Between the differences
> > I have:- glibc-2.28  (works)    => glibc-2.29 (doesn't work)- json-
> > c-0.12            => json-c-0.13.1- talloc-2.1.14          =>
> > talloc-2.2.0Is there a specific library that is used by unlang
> > parser? Could berelated to glibc or talloc? On Wed, 2019-06-26 at
> > 14:03 -0400, Alan DeKok wrote:
> > > On Jun 26, 2019, at 1:01 PM, Geaaru <geaaru at gmail.com> wrote:
> > > > I saw your patch on upstream and I dunno if your commits
> > > > covercompletely this use case.
> > > 
> > >  It doesn't fix it.
> > > > But if could help, now I have a different stack for the
> > > > exceptionwith your last changes:
> > > 
> > >  It now complains when the problem occurs, and not many
> > > functionslater. I've tracked it down to exactly the situation
> > > that needs to befixed.  We should have a fix in a few days. Alan
> > > DeKok.
> > -List info/subscribe/unsubscribe? See 
> > http://www.freeradius.org/list/devel.html