Memory leak in luci jsonc lib

I noticed this leak in luci.jsonc well tracking down a leak in a lua library I am developing.

here's a script to replicate the error

local jsonc = require "luci.jsonc"
local parser = jsonc.new();

local json = "{\"foo\":, \"bar\"}";

local function parse_json(json)
        local t = jsonc.parse(json);
        print(t.foo)
end

parse_json(...)
hostle@:~/kasa$ valgrind lua test-jsonc.lua {"foo":"bar"}
==218394== Memcheck, a memory error detector
==218394== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==218394== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==218394== Command: lua test-jsonc.lua {"foo":"bar"}
==218394== 
bar
==218394== 
==218394== HEAP SUMMARY:
==218394==     in use at exit: 46 bytes in 1 blocks
==218394==   total heap usage: 607 allocs, 606 frees, 64,889 bytes allocated
==218394== 
==218394== LEAK SUMMARY:
==218394==    definitely lost: 46 bytes in 1 blocks
==218394==    indirectly lost: 0 bytes in 0 blocks
==218394==      possibly lost: 0 bytes in 0 blocks
==218394==    still reachable: 0 bytes in 0 blocks
==218394==         suppressed: 0 bytes in 0 blocks
==218394== Rerun with --leak-check=full to see details of leaked memory
==218394== 
==218394== For lists of detected and suppressed errors, rerun with: -s
==218394== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

I have not had a chance to take a closer look at the jsonc.c file. I have however narrowed it down to the parse function, each call to parse leaks 1 block of 46bytes, the length of the input has no influence on the leak. I will have some time next week to have a close look at it ... I will start a ticket then if necessary, i am just to busy to commit the time presently, so i thought i'd just give a heads up

Hostle

ubus call system board

and lua version? Have you tried on like debian if that is upstream feature?

hostle@hostle:~$ uname -a

Linux hostle.development.tech 6.5.0-41-generic #41~22.04.2-Ubuntu SMP PREEMPT_DYNAMIC Mon Jun  3 11:32:55 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

hostle@hostle:~$ lua -v
Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio (double int32)

i do all development in ubuntu 22.04 so i have access to tools like valgrind and gdb .. then cross-compile and test in ow as a last step.

As i mentioned, i have not done any investigating other than narrowing it down to the parse function. I do use json-c in many C projects, some very recently and have had no issues using the upstream. I'll take a closer look this evening.

This is not ubuntu support forum as you might know.

yes ...quite aware. luci jsonc memory leak is the topic .. you are more than welcome to compile valgrind for ow and run it on luci jsonc and you will get the same lost memory. Just thought I'd bring it to the attention to those who understand, what i have presented

You need to trace to code line which leaks memory. and probably demo a leak of dozen to thousands lost pointers.

Not sure that's how i'd go about tracing the leak .. but let us know how you make out . maybe I should just run a loop calling parse and see what the kernel says lol

it would likely say ...that''ll be all, donkey

1 Like

You need to build more debug-ish versions to point to allocating code.

this might help Jow ..

==224075== Memcheck, a memory error detector
==224075== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==224075== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==224075== Command: lua test-jsonc.lua {"foo":"bar"}
==224075== 
bar
==224075== 
==224075== HEAP SUMMARY:
==224075==     in use at exit: 46 bytes in 1 blocks
==224075==   total heap usage: 609 allocs, 608 frees, 64,943 bytes allocated
==224075== 
==224075== 46 bytes in 1 blocks are definitely lost in loss record 1 of 1
==224075==    at 0x484DCD3: realloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==224075==    by 0x4A5665B: argz_add_sep (argz-addsep.c:34)
==224075==    by 0x49E3FFB: newlocale (newlocale.c:111)
==224075==    by 0x5066BBE: ???
==224075==    by 0x485D985: ???
==224075==    by 0x116ADC: luaD_precall (in /usr/local/bin/lua)
==224075==    by 0x1214A7: luaV_execute (in /usr/local/bin/lua)
==224075==    by 0x11714C: luaD_call (in /usr/local/bin/lua)
==224075==    by 0x116452: luaD_rawrunprotected (in /usr/local/bin/lua)
==224075==    by 0x1172F3: luaD_pcall (in /usr/local/bin/lua)
==224075==    by 0x11445B: lua_pcall (in /usr/local/bin/lua)
==224075==    by 0x10FF0A: docall (in /usr/local/bin/lua)
==224075== 
==224075== LEAK SUMMARY:
==224075==    definitely lost: 46 bytes in 1 blocks
==224075==    indirectly lost: 0 bytes in 0 blocks
==224075==      possibly lost: 0 bytes in 0 blocks
==224075==    still reachable: 0 bytes in 0 blocks
==224075==         suppressed: 0 bytes in 0 blocks
==224075== 
==224075== For lists of detected and suppressed errors, rerun with: -s
==224075== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

it would be helpful if someone could actually run valgrind against it from within the ow env. I don't have a unit handy big enough to fit the valgrind pkgs and don't have the time to get one setup. tho looking at the full log points to the lua executable, and I recall having a little go with getting lua compiled with the patches applied.

i will wait to open a ticket until i can confirm it not something to do with my liblua built for the host. I can say for certain that any lua modules i have built for ow using these methods compiled with the same liblua all work fine and memory always checks out. In the meantime if someone can build valgrind for ow (or install the pre-b's and confirm the leak .. that'd be super duper

well ... false alarm its seems. I should have looked into it further before blowing the whistle. No leak in ow.. and if one was to run it in ubuntu with the proper permissions set ...

hostle@:~/kasa$ sudo valgrind --leak-check=full lua test-jsonc.lua '{"foo":"bar"}'
==224563== Memcheck, a memory error detector
==224563== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==224563== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==224563== Command: lua test-jsonc.lua {"foo":"bar"}
==224563== 
bar
==224563== 
==224563== HEAP SUMMARY:
==224563==     in use at exit: 0 bytes in 0 blocks
==224563==   total heap usage: 607 allocs, 607 frees, 64,867 bytes allocated
==224563== 
==224563== All heap blocks were freed -- no leaks are possible
==224563== 
==224563== For lists of detected and suppressed errors, rerun with: -s
==224563== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

As soon as i ran the full leak check it was apparent. hopefully the only time wasted was my own

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.