Bugfix/segfault in log

[steweg]

No description provided.

[michalvasko]

When does this occur? Even the comment says that the error code is being inherited, if there is no previous error, it is probably a bug.

[steweg]

I was not able to quickly determine that as I was working with very complex data when it happens. I have pinpoint it using valgrind, but anyway I will dig further and let you know

[steweg]

I was able to recreate it, but I was not able to find out how to better fix it. Here is what is needed to reproduce:
a.yang file:

module a {
  namespace "a";
  prefix a;
  list a {key a1; leaf a1 {type string;} leaf a2 {type string;}}
  leaf b {type leafref {path "../a/a1";}}
  leaf c {type leafref {path "deref(../b)/../a2";}}
}

a.json file:

{
  "a:a": [{"a1": "valA1", "a2": "valB1"}, {"a1": "valA2", "a2": "valB2"}],
  "a:b": "valC1",
  "a:c": "valB1"
}

Output of the following command:

valgrind --exit-on-first-error=yes  --leak-check=full --show-leak-kinds=all --error-exitcode=1 yanglint a.yang -X -f json a.json
==29657== Memcheck, a memory error detector
==29657== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==29657== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==29657== Command: yanglint a.yang -X -f json a.json
==29657==
==29657== Invalid read of size 4
==29657==    at 0x486E476: log_vprintf (log.c:642)
==29657==    by 0x486E8AC: ly_log (log.c:717)
==29657==    by 0x49874D5: xpath_deref (xpath.c:4078)
==29657==    by 0x49941FD: eval_function_call (xpath.c:8746)
==29657==    by 0x4994B0B: eval_path_expr (xpath.c:8936)
==29657==    by 0x499700F: eval_expr_select (xpath.c:9633)
==29657==    by 0x499752E: lyxp_eval (xpath.c:9741)
==29657==    by 0x496EE28: lyplg_type_resolve_leafref (plugins_types.c:1050)
==29657==    by 0x49A59C9: lyplg_type_validate_leafref (leafref.c:83)
==29657==    by 0x4897968: lyd_value_validate_incomplete (tree_data_common.c:563)
==29657==    by 0x499920B: lyd_validate_unres (validation.c:389)
==29657==    by 0x499D6F9: lyd_validate (validation.c:1871)
==29657==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
==29657==
==29657==
==29657== Exit program on first error (--exit-on-first-error=yes)

Hope it helps

[michalvasko]

I have just decided to get rid of this "feature", not a good idea in general. So unless I missed a use-case (the one you posted works), it should be fixed.

[steweg]

Ok, closing this PR