Cellular Network Infrastructure » Radio Access Network » OsmoBSC

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.

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?

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.