TMPL_TYPE_LITERAL has non-zero bytes in its data union

[Geaaru]

Yeah, I did that. Thanks. But the weird thing is that this happens in
different configurations:
This seems that first use case (if I drop all operations and I leave
this):
  authorize {
          if (&Control:Auth-Type == "CHAP") {
          }
  }
the exception is visible from my side.
It seems related to Control:Auth-Type but for example this works:
  authorize {

      if (!&Control:Auth-Type || &Control:Auth-Type != "Accept") {

      }
  }
and also this it works:
  authorize {
      if (!&Control:Auth-Type || &Control:Auth-Type != "Accept") {
          if (&Control:Auth-Type) {
          } elsif (&Control:Auth-Type) {
          }
    }
  }
and also this it works:
  authorize {
      if (!&Control:Auth-Type || &Control:Auth-Type != "Accept") {
          if (&Control:Auth-Type == "Reject") {
          } elsif (&Control:Auth-Type == "Accept") {
          }
    }
  }
It's weird. It seems related to the comparison of &Control:Auth-Type to
string "CHAP" or "PAP".

On Wed, 2019-06-26 at 09:29 -0400, Alan DeKok wrote:
> On Jun 26, 2019, at 8:55 AM, Geaaru <geaaru at gmail.com> wrote:
> > It seems not related to linking. I try to investigate a bit if
> > could be related to my external module of OCI LIb or other.
> 
>   It shouldn't be.
> > #10 0x0000555555581f87 in load_component_section
> > (cs=0x555555a76930, components=0x555555d5edb0, comp=MOD_AUTHORIZE)
> > at /home/geaaru/Projects/freeradius-server/src/main/modules.c:1241
> 
>   That's just debugging the things it loaded from the "authorize"
> section.
>   My $0.02 is to comment out bits of the "authorize" section until it
> no longer crashes.  That configuration, then, is the one causing the
> issue.
>   Once we know what config causes the issue, the fix should be
> simple.
>   Alan DeKok.