make test in master fail - json
Debian wheezy, make test in master (19d03eeb44c66e2) fails: Failed evaluating jpath: Invalid cast from integer64 to integer Comment out tests 31, 32, 33 and 34 from tests/modules/json/eval.unlang and all is OK. There are comments there something about json-c < 0.10. This is json-c 0.10 (debian 0.10-1.2), so I guess it could be that 0.10 is broken as well? Or just something in flux in master. $ uname -a Linux elk 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u3 x86_64 GNU/Linux Matthew Mon Sep 14 22:51:26 2015 : Debug: (0) update request { Mon Sep 14 22:51:26 2015 : Debug: (0) &Tmp-String-0 := "[9223372036854775807, -9223372036854775807, 18446744073709551615, [ 21474 83647, -2147483647, 4294967295, ] ]" Mon Sep 14 22:51:26 2015 : Debug: (0) --> overwriting '{\"my_array\": [0, 1, 2, 3, 4, 5], \"my_object\": { \"foo\": \"bar\", \" num\" : 42 }, \"num\": 99, \"double\": 5.9, \"null\": null, \"bool_true\": true, \"bool_false\": false }' with '[9223372036854775807, -92 23372036854775807, 18446744073709551615, [ 2147483647, -2147483647, 4294967295, ] ]' Mon Sep 14 22:51:26 2015 : Debug: (0) } # update request = noop Mon Sep 14 22:51:26 2015 : Debug: (0) redundant (null) { Mon Sep 14 22:51:26 2015 : Debug: (0) group { Mon Sep 14 22:51:26 2015 : Debug: (0) map json &Tmp-String-0 { Mon Sep 14 22:51:26 2015 : ERROR: (0) Failed evaluating jpath: Invalid cast from integer64 to integer Mon Sep 14 22:51:26 2015 : Debug: (0) } # map json &Tmp-String-0 = fail Mon Sep 14 22:51:26 2015 : Debug: (0) } # group = fail Mon Sep 14 22:51:26 2015 : Debug: (0) modsingle[authorize]: calling noop (rlm_always) for request 0 Mon Sep 14 22:51:26 2015 : Debug: (0) modsingle[authorize]: returned from noop (rlm_always) for request 0 Mon Sep 14 22:51:26 2015 : Debug: (0) [noop] = noop Mon Sep 14 22:51:26 2015 : Debug: (0) } # redundant (null) = noop Mon Sep 14 22:51:26 2015 : Debug: (0) if (noop || (&Tmp-Integer-0 == 4294967295)) { Mon Sep 14 22:51:26 2015 : Debug: (0) if (noop || (&Tmp-Integer-0 == 4294967295)) -> TRUE Mon Sep 14 22:51:26 2015 : Debug: (0) if (noop || (&Tmp-Integer-0 == 4294967295)) { Mon Sep 14 22:51:26 2015 : Debug: (0) policy test_pass { Mon Sep 14 22:51:26 2015 : Debug: (0) update control { Mon Sep 14 22:51:26 2015 : Debug: (0) EXPAND %{expr:%{%{control:Tmp-String-8}:-0} + 1} Mon Sep 14 22:51:26 2015 : Debug: (0) --> 32 Mon Sep 14 22:51:26 2015 : Debug: (0) &Tmp-String-8 := "32" Mon Sep 14 22:51:26 2015 : Debug: (0) --> overwriting '31' with '32' Mon Sep 14 22:51:26 2015 : Debug: (0) &Auth-Type := Accept Mon Sep 14 22:51:26 2015 : Debug: (0) --> overwriting 'Accept' with 'Accept' Mon Sep 14 22:51:26 2015 : Debug: (0) } # update control = noop Mon Sep 14 22:51:26 2015 : Debug: (0) } # policy test_pass = noop Mon Sep 14 22:51:26 2015 : Debug: (0) } # if (noop || (&Tmp-Integer-0 == 4294967295)) = noop Mon Sep 14 22:51:26 2015 : Debug: (0) ... skipping else for request 0: Preceding "if" was taken Mon Sep 14 22:51:26 2015 : Debug: (0) map json &Tmp-String-0 { Mon Sep 14 22:51:26 2015 : ERROR: (0) Failed evaluating jpath: Invalid cast from integer64 to integer Mon Sep 14 22:51:26 2015 : Debug: (0) } # map json &Tmp-String-0 = fail Mon Sep 14 22:51:26 2015 : Debug: (0) } # authorize = fail Mon Sep 14 22:51:26 2015 : Debug: (0) Using Post-Auth-Type Reject Mon Sep 14 22:51:26 2015 : Debug: (0) Post-Auth-Type sub-section not found. Ignoring. Mon Sep 14 22:51:26 2015 : Debug: (0) } # server default Mon Sep 14 22:51:26 2015 : Debug: (0) Virtual server sending reply Access-Reject Output file build/tests/modules/json/eval.attrs does not match attributes in filter build/tests/modules/json/eval.attrs (Attribute value "Response-Packet-Type = Access-Reject" didn't match filter: Response-Packet-Type == Access-Accept) # build/tests/modules/json/eval.log MODULE_TEST_DIR=src/tests/modules/json/ MODULE_TEST_UNLANG=src/tests/modules/json/eval.unlang build/make/jlibtool --quiet --mode=execute ./build/bin/local/unittest -D share -d src/tests/modules/ -i build/tests/modules/json/eval.attrs -f build/tests/modules/json/eval.attrs -xx -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 14 Sep 2015, at 22:58, Matthew Newton <mcn4@LEICESTER.AC.UK> wrote:
Debian wheezy, make test in master (19d03eeb44c66e2) fails:
Failed evaluating jpath: Invalid cast from integer64 to integer
Comment out tests 31, 32, 33 and 34 from tests/modules/json/eval.unlang and all is OK.
There are comments there something about json-c < 0.10. This is json-c 0.10 (debian 0.10-1.2), so I guess it could be that 0.10 is broken as well? Or just something in flux in master.
Weird, it doesn't break in travis with json-c 0.9, it doesn't break on OSX with json-c 0.12. I guess there was some weird transitional thing in json-c 0.10 *sigh*. I'll try and track it down. The comments about json-c < 0.10 are because 0.10 was the first get support for 64 bit integers (supposedly). json-c is definitely the worst dependency in the server because a lot of the functionality we use was added in later versions. There's a set of h/c files just to fill in the gaps. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Mon, Sep 14, 2015 at 11:47:25PM +0100, Arran Cudbard-Bell wrote:
On 14 Sep 2015, at 22:58, Matthew Newton <mcn4@LEICESTER.AC.UK> wrote: Debian wheezy, make test in master (19d03eeb44c66e2) fails: ... There are comments there something about json-c < 0.10. This is json-c 0.10 (debian 0.10-1.2), so I guess it could be that 0.10 is broken as well? Or just something in flux in master.
Weird, it doesn't break in travis with json-c 0.9, it doesn't break on OSX with json-c 0.12. I guess there was some weird transitional thing in json-c 0.10 *sigh*.
OK, additional reference. Jessie with libjson0 0.11-4 works fine. Though can't guarantee the build environments are similar in any way (just my two desktop systems, not clean Debian installs).
The comments about json-c < 0.10 are because 0.10 was the first get support for 64 bit integers (supposedly).
Righto. Looks suspiciously like "supposedly" :) Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 14 Sep 2015, at 23:59, Matthew Newton <mcn4@LEICESTER.AC.UK> wrote:
On Mon, Sep 14, 2015 at 11:47:25PM +0100, Arran Cudbard-Bell wrote:
On 14 Sep 2015, at 22:58, Matthew Newton <mcn4@LEICESTER.AC.UK> wrote: Debian wheezy, make test in master (19d03eeb44c66e2) fails: ... There are comments there something about json-c < 0.10. This is json-c 0.10 (debian 0.10-1.2), so I guess it could be that 0.10 is broken as well? Or just something in flux in master.
Weird, it doesn't break in travis with json-c 0.9, it doesn't break on OSX with json-c 0.12. I guess there was some weird transitional thing in json-c 0.10 *sigh*.
OK, additional reference. Jessie with libjson0 0.11-4 works fine. Though can't guarantee the build environments are similar in any way (just my two desktop systems, not clean Debian installs).
The comments about json-c < 0.10 are because 0.10 was the first get support for 64 bit integers (supposedly).
Righto. Looks suspiciously like "supposedly" :)
Weird weird things. Can you test on your system as see if all JSON integer values produce INT32_MAX/INT32_MIN/INT64_MAX/INT64_MIN? This does not happen with json-c 0.9. As they seem to on mine, which is why the tests are failing. I even modified the code to avoid casts from 32->64 bits and it's still producing junk values. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Tue, Sep 15, 2015 at 07:34:49PM +0100, Arran Cudbard-Bell wrote:
The comments about json-c < 0.10 are because 0.10 was the first get support for 64 bit integers (supposedly).
Righto. Looks suspiciously like "supposedly" :)
Weird weird things.
Can you test on your system as see if all JSON integer values produce INT32_MAX/INT32_MIN/INT64_MAX/INT64_MIN?
Don't think so - this passes: update request { &Tmp-String-0 := "\ [\ 4, \ -9, \ 1 \ ]" } map json &Tmp-String-0 { &Tmp-Integer-7 := '$[0]' } if (&Tmp-Integer-7 == "4") { test_pass } else { test_fail } But if I use [9223372036854775807, -9223372036854775807, 18446744073709551615] as the string, it fails: Debug: (0) map json &Tmp-String-0 { ERROR: (0) Failed evaluating jpath: Invalid cast from integer64 to integer Debug: (0) } # map json &Tmp-String-0 = fail So there doesn't seem to be a problem with 32bit ints. I've got both amd64 and i386 versions of libjson installed: $ dpkg --get-selections | grep libjson0 libjson0:amd64 install libjson0:i386 install libjson0-dev:amd64 install $ so wondered if it had linked against the i386 one for some reason, but: $ ldd /opt/fr31/lib/libfreeradius-json.so linux-vdso.so.1 => (0x00007ffe363f4000) libjson.so.0 => /lib/x86_64-linux-gnu/libjson.so.0 (0x00007fe7ea48e000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe7ea103000) /lib64/ld-linux-x86-64.so.2 (0x00007fe7ea8bb000) so that looks OK. Just ripped libjson0:i386 off and it's still the same error. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
participants (2)
-
Arran Cudbard-Bell -
Matthew Newton