When you create something new, there's one lock on it already. The lock count is effectively the amount of pointers there are floating around.
Always on the 255th HTTP request
That's very interesting... If you compare the trace() between HTTP requests, what about the [r#l#] tags that get printed? In that case it sounds to me like the reference count has overflowed in that variable (so not jsvLock but jsvRef) - on 12 byte var systems it's a single byte.
Could you add an assert(jsvGetRefs(var)); line after:
.. so checking that adding 1 didn't cause the ref count to overflow.
Generally I haven't bothered checking for overflowed refs because the reffing only gets done internally and doesn't usually go wrong, but it could be that in this case something has gone wrong.
to me it looks like connection objects just don't get freed
It could be there's a circular reference - for instance the scope of a #ondata handler could reference an #onconnect call in which one of the parameters would be the connection object.
It'd mean it wasn't automatically freed, but a mark/sweep garbage collection pass (which happens when Espruino is idle or runs out of memory during execution) would realise and then free it.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
It's here? https://github.com/espruino/Espruino/blob/master/libs/network/jswrap_net.c#L161
When you create something new, there's one lock on it already. The lock count is effectively the amount of pointers there are floating around.
That's very interesting... If you compare the
trace()
between HTTP requests, what about the[r#l#]
tags that get printed? In that case it sounds to me like the reference count has overflowed in that variable (so notjsvLock
butjsvRef
) - on 12 byte var systems it's a single byte.Could you add an
assert(jsvGetRefs(var));
line after:https://github.com/espruino/Espruino/blob/master/src/jsvar.c#L566
.. so checking that adding 1 didn't cause the ref count to overflow.
Generally I haven't bothered checking for overflowed refs because the reffing only gets done internally and doesn't usually go wrong, but it could be that in this case something has gone wrong.
It could be there's a circular reference - for instance the scope of a
#ondata
handler could reference an#onconnect
call in which one of the parameters would be the connection object.It'd mean it wasn't automatically freed, but a mark/sweep garbage collection pass (which happens when Espruino is idle or runs out of memory during execution) would realise and then free it.