TMPL_TYPE_LITERAL has non-zero bytes in its data union
jpereira at freeradius.org
Fri Jul 5 20:45:58 CEST 2019
Take a look at the libkqueue version.
> 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 :)
> On Fri, 2019-07-05 at 14:36 -0300, Jorge Pereira wrote:
>> 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:
>>> 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-
>>> 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
>>>> 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
More information about the Freeradius-Devel