TMPL_TYPE_LITERAL has non-zero bytes in its data union

[Jorge Pereira]

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 where
>>> code with PAP/CHAP condition works perfectly, but now with the same
>>> 3.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.0
>>> Is there a specific library that is used by unlang parser? Could be
>>> related 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 cover
>>>>> completely this use case.
>>>> 
>>>>  It doesn't fix it.
>>>>> But if could help, now I have a different stack for the exception
>>>>> with your last changes:
>>>> 
>>>>  It now complains when the problem occurs, and not many functions
>>>> later.
>>>>  I've tracked it down to exactly the situation that needs to be
>>>> fixed.  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>
>>