TMPL_TYPE_LITERAL has non-zero bytes in its data union

[Geaaru]

Hi,
this issue is on 3.0.x branch (not tested on master branch) and I don't
use libkqueue.
I downgrade to talloc-2.1.14 (also 2.1.9) and I have the same issue.
But it seems that happens only if it's enabled -Xx debug. If I disable
debug freeradius bootstrap correctly.So, probably this means that I'm
not sure that libraries currently in production haven't the issue
because debug is disabled.
But I'm sure that this configuration in the past worked correctly also
with debug. It's very weird.
I executed a test also with tagged version 3.0.16 and 3.0.15 and I
reproduced the same issue.
I will investigate a bit on FreeRadius parser for try to indentify the
issue.

On Fri, 2019-07-05 at 15:45 -0300, Jorge Pereira wrote:
> Take a look at the libkqueue version.—Jorge Pereira
> 
> 
> 
> > On 5 Jul 2019, at 14:42, Geaaru <geaaru at gmail.com> wrote:
> > 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/013544.html>
> > ;- 
> > http://lists.freeradius.org/pipermail/freeradius-devel/2019-June/013554.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
> > > >  <mailto: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
> > > > >  <mailto: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
> > > >  <http://www.freeradius.org/list/devel.html>
> 
> -List info/subscribe/unsubscribe? See 
> http://www.freeradius.org/list/devel.html