You are reading a single comment by @Gordon and its replies. Click here to read the full conversation.
  • could you tell me where 'key' gets locked in github.com/espruino/Espruino/blob/master­/libs/network/jswrap_net.c#L169-L172

    It's here? https://github.com/espruino/Espruino/blo­b/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.

    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:

    https://github.com/espruino/Espruino/blo­b/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.

    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.

About

Avatar for Gordon @Gordon started