OBK Heap Drops Under Repeated Large HTTP Requests - leak/realloc question

I have a question. I've been trying to make OBK fallover by spamming it with repeated oversized http requests.

Using this:





and with 1.18.253 I get this kind of dropping heap until device reboots, not always, but mostly, especially if clicking about in the gui. This device has MQTT, HA, BL0937 configured.


with these changes https://github.com/openshwprojects/OpenBK7231...mpare/main...divadiow:OpenBK7231T_App:tcpleak

I can run the stress-test script over and over with seemingly little effect. (starting HA discovery drops heap to 30k from which it doesn't seem to recover - maybe that's a different issue or to be expected?)



is this a realloc bug?

Ahh yes, fair point, you have figured it out well.

In the low heap scenario, realloc fails to reallocate the memory, so it returns NULL, but original pointer is not invalidated. So, by overwriting request.received with returned NULL, we orphan the original (still correct) buffer.

oh cool. so it was something to bring up.

https://github.com/openshwprojects/OpenBK7231T_App/pull/1990

Yes, great finding, keep it on! It's possible that wrong realloc usage pattern repeats somewhere else in the codebase.

Just extra question - why return has changed to goto exit?

p.kaczmarek2 wrote:

why return has changed to goto exit?

so the path still hits the function's unified cleanup block. The return would skip those and leak the already-allocated buffers and socket resources.

is the answer i'm being given

p.kaczmarek2 wrote:

it's possible that wrong realloc usage pattern repeats somewhere else in the codebase.

yes, potentials to be investigated:

src/driver/drv_adcSmoother.c — realloc clobber + NULL memset; possible divide-by-zero if window unset/0
src/driver/drv_girierMCU.c — queue buffer realloc clobber; no failure handling; bookkeeping corruption
src/driver/drv_httpButtons.c — list realloc clobber + NULL deref; also prints bt->label before NULL check
src/driver/drv_pixelAnim.c — work-buffer realloc clobber; “OOM handling” still leaks old buffer
src/driver/drv_tuyaMCU.c — multiple realloc clobbers (queue data, payload buffers, rawData); immediate memcpy/usage after

src/httpserver/hass.c — unbounded strcat into small static buffer (overflow risk)
src/httpserver/hass.c + src/httpserver/hass.h — unique_id sizing mismatch when appending title (overflow risk)

src/cmnds/cmd_script.c — realloc clobber; state updated before success (OOM inconsistency)
src/cmnds/cmd_tokenizer.c — fixed 20-byte ${…} buffer overflow risk for long tokens

Perfect, merged, proceed to futher links and show me solutions one by one. I want to review them, because automated methods still gives false positives.

thanks for merging!

p.kaczmarek2 wrote:

I want to review them, because automated methods still gives false positives.

for sure. I double, triple, quadruple etc check with LLM (new chats, different contexts, different questions etc) and, if necessary, confirm with other tools too. eg:



Added after 5 [minutes]:

it's fascinating seeing what these tools have to say about the code. opens up another world of things to look into, wondering if these *are* real issues requiring attention, what does and doesn't matter...


Added after 10 [minutes]:

this is that report if curious

Just a quick feedback about the initial http code:
In my PR I also limited the maximum buffer size. What do you think about this?

In most cases that should not be necessary:
If buffer is to small, we reallocate a 1024 bytes bigger one.
Since there's no limit, we will fail at some point if input data is huge.
As long there is no other process claiming memory, we will roughly take half of the memory: every realloc needs "actual buffer"*2 +1024 to succeed, so a successful realloc must leave as free round half of the memory -1k on that point.

The smaller free memory is , the smaller the memory left when realloc fails.

Is this sufficient or should we limit the buffer from the beginning?
Is my description above even correct and complete?

max4elektroda wrote:

What do you think about this?

I guess this was directed at p.kaczmarek2 because I don't have the knowledge or experience from which to answer

whatever's better/a good thing is my obvious preference. that goes without saying though

Yes it was a general question to whoever thinks fit to answer or decide