Re: FYI, Epoc memory-leak...

["Andrew Wheeler" <awheeler@...>]

> I've ported Lua to EPOC, and I'm not an EPOC expert (indeed, the Lua port
> was the first bit of non-OPL programming I'd done on EPOC), so I didn't
know
> about this problem.

It's a common issue - as I mentioned the Symbian folks bury any mention of
the call deep in their SDK (and only mention it once).

>
> I suppose that the obvious place to put the call to CloseSTDLIB() is in
> lua_close(), but the Lua docs say that you don't have to call lua_close().
>
> Also, in my port, Lua is supplied as a DLL, so will a call to CloseSTDLIB
be
> made in the correct context there, i.e. when an app calls lua_close()
(which
> is in a DLL), will it be that app's STDLIB context that is "finalised"?

yah, good point.  I haven't dug into CloseSTDLIB(), but the docs state that
it deallocates the DLL's "thread-local storage" structure, _reent.  From
what I can gather, it seems that this deallocation will not cause any
catostrophic problems so long as the main app/exe no longer attempts to use
any of its STDLIB pointers or handles.  These handles include all
file-handles other than _STDOUT, _STDIN, and _STDERR (which are constants):
once CloseSTDLIB() is called in a thread you must assume all files are
closed and the handles are invalid.  Otherwise, since there's no STDLIB
Init() function, I'll wager the library is smart enough to (re)allocate the
_reent structure if/when needed: i.e., if you attempt to open a file after
calling CloseSTDLIB(), it will be able to open the file: but it will just
take a little bit of extra time to re-construct the thread-local storage.  I
haven't tested this, but I imagine it's the case...

Regardless, the constraint of losing all your file-handles after calling
CloseSTDLIB() will not be acceptable to all developers.  That being said,
off the top of my head I can think of three workarounds:

                         - status-quo, but document the issue: leave it up
to the developer to call CloseSTDLIB().
                         - construct a (external) reference counter for
STDLIB and document both its necessity and usage.
                         - don't use STDLIB in the DLL's.

So the first workaround seems the best-suited for lua; option two seems more
appropriate for larger projects that use lua, as well as other
STDLIB-dependent DLL's; and option three is for those projects where
developer codability and end-user experience is more important than the sw
maintenance cost of porting new lua releases to a non STDLIB-using Epoc
environment.  (I mention end-user experience because STDLIB doesn't ship
with all the Epoc devices: "Joe Psion" has to manually install STDLIB onto
his 5mx).


>
> In any case, I presume that if you have a normal C app compiled against
the
> library, it will implicitly call CloseSTDLIB when it exits, so doesn't
need
> this call (or worse, may crash if it's already been made).

CloseSTDLIB() is not called, but the memory is cleaned up when
the -executable- (foo.exe) is terminated.  EIKON GUI-based applications
(foo.app), however, are not guaranteed to perform garbage-collection when
the app is exited: I believe this is why our Symbian friends added
CloseSTDLIB().

I have tested calling CloseSTDLIB() multiple times at app-exit, and that
seems to work just fine: this makes sense if all the call is doing is
cleaning up the thread-local storage.  But I'd want to dig a bit deeper
before a product-ship.... ;-)

>
> And what about OPL applications that use the Lua OPX? Where (if at all)
> should CloseSTDLIB be called for them?

Unfortunately I know almost nothing about OPX.  But I gather that, since OPL
probably sits on top of EIKON and probably doesn't use STDLIB, to be 100%
safe you'd have to explicitly call CloseSTDLIB() before the application
exits.

>
> I'd appreciate some guidance on this. Also on when exactly the app will
leak
> memory, and how much. I've not noticed any memory leak on my Revo (I even
> deleted MemFree a little while ago because in over a year of use it had
> never found any memory to reclaim), but I could be missing something...

I don't know how big the _res

EPOC is pretty darn good at protecting against memory-leaks, but
unfortunately, due to the weird architecture of the EIKON apps,  developers
cannot always depend on the OS's garbage-collection.  Fortunately, however,
the Symbian developers have provided a reasonable dev-environment for
finding memory-leaks: all EIKON debug-builds (on at least the emulator)
enable memory-leak detection automatically, and executables can enable the
memory-leak detection fairly easily: take a look at __UHEAP_MARKEND in the
SDK documentation.  I actually write quite a bit of cross-platform code for
EPOC and WinCE, and I mostly depend on the EPOC emulator to alert me about
my unfortunate fortitude memory leaks.  ;-)

-andrew