Feature #2781
openExtend OsmBSC TTCN-3 test coverage regarding resource leaks
60%
Description
let's collect ideas about what we need to test here
Checklist
- check for memory leaks of bsc_subscriber
- check for memory leaks of bsc_subscriber_conn
- check for memory leaks of SCCP connections
Related issues
Updated by laforge almost 5 years ago
- Subject changed from Extend OsmBSC TTCN-3 test coverage to Extend OsmBSC TTCN-3 test coverage regarding resource leaks
Updated by laforge almost 5 years ago
- Related to Feature #2712: implement reproducible talloc context printout, i.e. without memory addresses added
Updated by fixeria about 2 years ago
- Related to Bug #2780: OsmoBSC memory leak on bsc_subscriber added
Updated by fixeria about 2 years ago
- Related to Bug #5355: ttcn3-bsc-test: leaked struct bsc_subscr in LCS tests added
Updated by fixeria about 2 years ago
- Related to Bug #5337: ttcn3-bsc-test: leaked struct bsc_subscr in BSC_Tests.TC_no_msc added
Updated by fixeria about 2 years ago
- Checklist item check for memory leaks of bsc_subscriber set to Done
- Checklist item check for memory leaks of bsc_subscriber_conn set to Done
- Status changed from New to Feedback
- Assignee set to neels
- % Done changed from 0 to 60
As far as I can see, in f_shutdown_helper() we do check for memory leaks of:
- struct bsc_subscr, and
- struct gsm_subscriber_connection.
Assigning to neels who implemented the related checks.
Updated by neels about 2 years ago
that's true, this check was added fairly recently in https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/26619
after subscr leaks were discovered and fixed in osmo-bsc.
Many BSC tests also required tweaks to properly release conns in the end.
If an SCCP conn also shows in the talloc_report as a distinct type of struct,
we can add the same check against SCCP leaks rather trivially
by adding the name to that talloc check...
These checks of course assume that each test runs alone without unrelated conns being active.
I think the original idea for TTCN3 tests was to at some point be able to run them in parallel.
The reality is that for years the tests are running one by one, so it seemed reasonable to require that they do.
Updated by neels about 2 years ago
well, the SCCP conn id is kept in struct bsc_subscriber_conn.
That means we already check for SCCP conn leaks, as far as osmo-bsc's state is concerned.
What else can we do, probably count the open conn IDs on TTCN3 side in the MSC_ConnectionHandler?
Updated by laforge about 2 years ago
Lets not add strange assumptions. The entire complex infrastructure we've built with protocol emulations dispatching different connections to different components makes no sense if you cannot run tests in parallel. I also do think we have (non BSC) tests where we do in fact already execute tests in parallel.