Comments (2)
elgerg
commented on July 28, 2024
Ok,
Having using valgrind to debug the app, it always look like it's in the json_object_put call that is trying to free memory that has been freed.
This to me seems a little odd given the order of add/removes IE:
void handleForecast(json_object *parsed_json)
{
struct json_object *weatherObj, *tmpWeather;
int exists = json_object_object_get_ex(parsed_json, "payload", &weatherObj);
if ( false == exists )
{
printf( "\"payload\" not found in JSON\n" );
return;
}
lv_mem_monitor_t mon;
lv_mem_monitor(&mon);
for (int i = 0; i < json_object_array_length( weatherObj ) && i < 20; i++ )
{
tmpWeather = json_object_array_get_idx( weatherObj, i );
struct json_object *dt_txt,
*feels_like,
*temp_min,
*temp_max,
*wmain,
*description,
*rain,
*icon,
*wind;
json_object_object_get_ex(tmpWeather, "dt_txt", &dt_txt);
json_object_object_get_ex(tmpWeather, "feels_like_raw", &feels_like);
json_object_object_get_ex(tmpWeather, "temp_min_raw", &temp_min);
json_object_object_get_ex(tmpWeather, "temp_max_raw", &temp_max);
json_object_object_get_ex(tmpWeather, "main", &wmain);
json_object_object_get_ex(tmpWeather, "description", &description);
json_object_object_get_ex(tmpWeather, "rain", &rain);
json_object_object_get_ex(tmpWeather, "wind", &wind);
json_object_object_get_ex(tmpWeather, "icon", &icon);
printf("Dt::::: feel: %s Cal: %s Min: %s Max: %s Main: %s Description: %s Rain: %s Wind: %s Icon: %s\n", json_object_get_string(dt_txt)
, json_object_get_string(feels_like)
, json_object_get_string(temp_min)
, json_object_get_string(temp_max)
, json_object_get_string(wmain)
, json_object_get_string(description)
, json_object_get_string(rain)
, json_object_get_string(wind)
, json_object_get_string(icon)
);
lv_label_set_text(temps.weatherItems[i].dt, json_object_get_string(dt_txt));
//lv_obj_del(temps.weatherItems[i].icon);
//temps.weatherItems[i].icon = lv_rlottie_create_from_file(weatherPage, LOTTIE_IMAGE_SIZE, LOTTIE_IMAGE_SIZE, resolve_owm_icon_lottie( json_object_get_string(icon) ));
int ramCurrent = (int)mon.total_size - mon.free_size;
printDateTime();
printf("Total Size: %d, Free Size: %d, Current %d\n", mon.total_size, mon.free_size, ramCurrent/10);
//lv_obj_align_to(temps.weatherItems[i].icon, temps.weatherItems[i].dt, LV_ALIGN_BOTTOM_MID, 10, 90);
lv_img_set_src(temps.weatherItems[i].icon, (lv_obj_t*)resolve_owm_icon( json_object_get_string(icon) ));
char strColour[7];
getColourForTemp(strColour, json_object_get_double(feels_like));
lv_label_set_text_fmt(temps.weatherItems[i].feels, "Feels: #%s %0.2f°c#", strColour, json_object_get_double(feels_like));
//lv_label_set_text(temps.weatherItems[i].feels, json_object_get_string(feels_like));
getColourForTemp(strColour, json_object_get_double(temp_min));
lv_label_set_text_fmt(temps.weatherItems[i].min, "Min: #%s %0.2f°c#", strColour, json_object_get_double(temp_min));
//lv_label_set_text(temps.weatherItems[i].min, json_object_get_string(temp_min));
getColourForTemp(strColour, json_object_get_double(temp_max));
lv_label_set_text_fmt(temps.weatherItems[i].max, "Max: #%s %0.2f°c#", strColour, json_object_get_double(temp_max));
//lv_label_set_text(temps.weatherItems[i].max, json_object_get_string(temp_max));
lv_label_set_text(temps.weatherItems[i].rain, json_object_get_string(rain));
lv_label_set_text(temps.weatherItems[i].wind, json_object_get_string(wind));
lv_label_set_text(temps.weatherItems[i].bmain, json_object_get_string(wmain));
lv_label_set_text(temps.weatherItems[i].desc, json_object_get_string(description));
json_object_put(dt_txt);
json_object_put(feels_like);
json_object_put(temp_min);
json_object_put(temp_max);
json_object_put(rain);
json_object_put(wind);
json_object_put(wmain);
json_object_put(description);
json_object_put(icon);
//json_object_put(tmpWeather);
}
//json_object_put(weatherObj);
}
Here is what valgrand says when the json_object_put(tmpWeather); is uncommented:
Invalid read of size 4
==136976== by 0x27BDA3: handleForecast (Callbacks.c:104)
IE: json_object_put(tmpWeather);
==136976== Address 0x60d93a4 is 4 bytes inside a block of size 65 free'd
==136976== by 0x27BD5B: handleForecast (Callbacks.c:94)
IE: json_object_put(dt_txt);
==136976== Invalid read of size 4
==136976== at 0x48C5CCC: json_object_put (in /usr/lib/aarch64-linux-gnu/libjson-c.so.5.2.0)
==136976== by 0x48CB7BF: lh_table_free (in /usr/lib/aarch64-linux-gnu/libjson-c.so.5.2.0)
==136976== by 0x48C5D5F: json_object_put (in /usr/lib/aarch64-linux-gnu/libjson-c.so.5.2.0)
==136976== by 0x27BDA3: handleForecast (Callbacks.c:104)
==136976== by 0x27E3F7: my_message_callback (MQTT.c:54)
==136976== by 0x48F7603: ??? (in /usr/lib/aarch64-linux-gnu/libmosquitto.so.2.0.11)
==136976== by 0x48FD4E7: ??? (in /usr/lib/aarch64-linux-gnu/libmosquitto.so.2.0.11)
==136976== by 0x48F8703: mosquitto_loop_read (in /usr/lib/aarch64-linux-gnu/libmosquitto.so.2.0.11)
==136976== by 0x48F8B37: mosquitto_loop (in /usr/lib/aarch64-linux-gnu/libmosquitto.so.2.0.11)
==136976== by 0x28B70F: tsk_runmosq (Tasks.c:15)
==136976== by 0x2566FB: lv_timer_exec (lv_timer.c:313)
==136976== by 0x25619F: lv_timer_handler (lv_timer.c:109)
==136976== Address 0x60d93a4 is 4 bytes inside a block of size 65 free'd
==136976== at 0x4887B40: free (in /usr/libexec/valgrind/vgpreload_memcheck-arm64-linux.so)
==136976== by 0x48C5D23: json_object_put (in /usr/lib/aarch64-linux-gnu/libjson-c.so.5.2.0)
==136976== by 0x27BD5B: handleForecast (Callbacks.c:94)
==136976== by 0x27E3F7: my_message_callback (MQTT.c:54)
==136976== by 0x48F7603: ??? (in /usr/lib/aarch64-linux-gnu/libmosquitto.so.2.0.11)
==136976== by 0x48FD4E7: ??? (in /usr/lib/aarch64-linux-gnu/libmosquitto.so.2.0.11)
==136976== by 0x48F8703: mosquitto_loop_read (in /usr/lib/aarch64-linux-gnu/libmosquitto.so.2.0.11)
==136976== by 0x48F8B37: mosquitto_loop (in /usr/lib/aarch64-linux-gnu/libmosquitto.so.2.0.11)
==136976== by 0x28B70F: tsk_runmosq (Tasks.c:15)
==136976== by 0x2566FB: lv_timer_exec (lv_timer.c:313)
==136976== by 0x25619F: lv_timer_handler (lv_timer.c:109)
==136976== by 0x1E6E1F: lv_task_handler (lv_api_map.h:37)
==136976== Block was alloc'd at
==136976== at 0x48850C8: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-arm64-linux.so)
==136976== by 0x48C541B: ??? (in /usr/lib/aarch64-linux-gnu/libjson-c.so.5.2.0)
==136976== by 0x48C9E03: json_tokener_parse_ex (in /usr/lib/aarch64-linux-gnu/libjson-c.so.5.2.0)
==136976== by 0x48CA4DF: json_tokener_parse_verbose (in /usr/lib/aarch64-linux-gnu/libjson-c.so.5.2.0)
==136976== by 0x48CA553: json_tokener_parse (in /usr/lib/aarch64-linux-gnu/libjson-c.so.5.2.0)
==136976== by 0x27E3AF: my_message_callback (MQTT.c:47)
==136976== by 0x48F7603: ??? (in /usr/lib/aarch64-linux-gnu/libmosquitto.so.2.0.11)
==136976== by 0x48FD4E7: ??? (in /usr/lib/aarch64-linux-gnu/libmosquitto.so.2.0.11)
==136976== by 0x48F8703: mosquitto_loop_read (in /usr/lib/aarch64-linux-gnu/libmosquitto.so.2.0.11)
==136976== by 0x48F8B37: mosquitto_loop (in /usr/lib/aarch64-linux-gnu/libmosquitto.so.2.0.11)
==136976== by 0x28B70F: tsk_runmosq (Tasks.c:15)
==136976== by 0x2566FB: lv_timer_exec (lv_timer.c:313)
==136976==
from json-c.
hawicz
commented on July 28, 2024
This is not a bug in json-c.
json_object_object_get_ex doesn't give you ownership of the object returned, it's still owned by the containing object so you must not call json_object_put on those returned objects.
All you need to do to free all memory used by a object tree is call json_object_put on the top-level object, presumably parsed_json in your example. (unless you've explicitly incremented reference counts somewhere with json_object_get)
from json-c.
Related Issues (20)
- Code execution order HOT 1
- Hi I need to generate libjson-c.so.3 and libjson-c.so.3.0.1, please help with steps HOT 1
- error: a function declaration without a prototype is deprecated in all versions of C HOT 6
- build with intel 2023 fails on vasprintf HOT 2
- ISO C forbids in HOT 2
- Any release planing for 0.17? HOT 2
- Symbol not found during linking stage of libjson-c.so HOT 1
- RFE: please start making github releases
- Cannot build with clang-cl HOT 3
- I am looking whether this CVE - CVE-2021-32292 is impacted by json-c version v0.13.1or not ? HOT 2
- memory leak issue in 0.13 HOT 1
- Null pointer dereference in tokener_parse_ex_fuzzer.cc HOT 1
- Cannot link properly using cmake HOT 2
- Memory leak when enable HAVE_SETLOCALE and HAVE_USELOCALE HOT 2
- Random crash in json_tokener_parse HOT 7
- Assignment bug in json_pointer.c HOT 2
- _WIN32 should be used, not WIN32 in source code ifdefs. HOT 2
- Doxygen: mis-wording in `json_object_put`
- Missing return description
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from json-c.