SmppClient SubmitSm Memory Leak - Objects Not Released (v2.9.35)

[IoJo]

Hi everyone,

I've identified a potential memory leak in the Inetlab.SMPP client library
when working with SubmitSm PDU creation.

Issue:
- Creating SubmitSm objects or using SMS.ForSubmit() does not properly release
memory after the objects are disposed or go out of scope.
- Memory profiler shows retained object references that prevent garbage collection.
- Problem is consistent across v2.9.35 and older versions I've tested.

Impact:
In high-message-throughput applications, this causes continuous memory growth
and eventual application slowdown or crash.

Workaround Needed:
Does anyone know if:
1. There's an explicit cleanup method beyond Dispose()?
2. This is a known issue with a planned fix?
3. An alternative method to create SubmitSm without memory retention?

Any help or similar experiences welcome. Happy to share profiler snapshots if needed.

[alt]

Hi IoJo,

Could you share one or two screenshots from your memory profiler, especially the “Path to GC root” for SubmitSm?

Please clarify:
- whether the retained objects belong to internal Inetlab collections or your own structures.
- whether the retention continues even after the SMPP client is cleanly disconnected and disposed.

Please note that each SubmitSm request is referenced by its corresponding SubmitSmResp. Both objects remain in memory until your code finishes processing the response.

[IoJo]

Hi alt

Following your instructions, I tested the application in more detail. I noticed that the memory usage starts to increase even before calling Sms.ForSubmit() or creating a new instance of DeliverSm().
This increase seems to be related to the call routes, as the footprint increases before any actual messages are sent or delivered.

Thank you for your help in finding this issue.