Security Manager Module Memory Documentation

Used OOM policies

All security manager interfaces return OOM errors through OP_STATUS return values.

Who is handling OOM?

Clients of the security manager interfaces are expected to handle or propagate the error.

Description of flow

Basically called from dom, gadgets and dochand modules to check security aspects like origin checks.

Heap memory usage

OpSecurityManager singleton is created on startup by the module object.

OpSecurityUtilities::InitializeTables() is using heap memory to store tables over know intranet addresses. These tables are generated on-demand, currently only in CheckGadgetSecurity().

The rest of the heap allocations are done for storing gadget policies parsed from xml.

Stack memory usage

Very little. No known recursions.

Caching and freeing memory

Intranet ranges table (OpSecurityUtilities::InitializeTables()) is created on demand and not freed until exit. The size of the table is very small.

Freeing memory on exit

All heap memory is pointed to via the OpSecurityManager singleton in the module object and is freed by the module object on exit.

Temp buffers

Current use of MemoryManager temporary buffers

Not used at all in this module.

Memory tuning

No tuning possible.

Tests

None.

Coverage

Run widgets with various policies and javascript running cross domain scripts.

The module selftest covers a lot of the code, but you need to force OOM in order to test the OOM behaviour.

Design choices

None of interest.

Possible improvements

GadgetUrlFilter::UrlFieldAsString uses a TempBuffer object whose storage is not ever freed until Opera exits. In edge cases of very long URLs or parts of URLs, it will take up a certain amount of heap which is not made available for the rest of the time Opera exists. This buffer should probably be freed for strings above a certain length.