AP_Scripting: Fix memory leak in LUA dataflash logging

[jschall]

No description provided.

[tpwrules]

I don't understand the motivation. This is technically more correct, but our allocator does not care about the size on free (though Lua does internally somewhat). So there is no memory leak that it fixes.

Please help me understand the problem, or adjust the commit message to clarify there is no actual leak. E.g. "AP_Scripting: fix Lua dataflash logging to correct garbage collector accounting". The actual issue here is minor.

[jschall]

Before change, memory use grew linearly over time.

After change, memory use was constant.

I'm not just throwing stuff at the wall. This is correct.

[tpwrules]

This PR indeed fixes an error in the accounting which might create that impression, but as far as I can tell there is no actual leak and I would like to confirm. How did you check?

[jschall]

By setting SCR_DEBUG_OPTS to 2 and watching memory increase, and then making this change and watching memory not increase.

[tpwrules]

Yes, that would show the accounting bug. But there is still no actual leak that I can tell.

In any case, there are several other places in this function that call luaM_free that also need a fix, so this PR needs revision.

Consider instead refactoring to use luaL_Buffer and luaL_buffinitsize. Then you can get rid of all the free calls, it is safe to abandon it.

[tpwrules]

In fact, please just make it a static 256 byte buffer. We can't have a message longer than that. Well we could, but that is a pre-existing bug that is broken with this.

[tpwrules]

Wrong button...

[tpwrules]

Thanks for reporting this. Should be fixed in that other PR.