Memory leak when extract attachments in PST

Aspose.Email Product Family
1

When I used ‘ExtractAttachments’ to parse attachments in a PST file, memory was not released. It appears that Dispose() method does not take effect.

 SharedPtr<PersonalStorage> pst = PersonalStorage::FromFile(pstFile, loadOptions);
 SharedPtr<FolderInfo> root = pst->get_RootFolder();
SharedPtr<FolderInfoCollection> subFolders = root->GetSubFolders();
for (int i = 0; i < subFolders->get_Count(); i++) {
        SharedPtr<FolderInfo> folder = subFolders->idx_get(i);
        SharedPtr<MessageInfoCollection> messages = folder->GetContents();
         for (int i = 0; i < messages->get_Count(); i++) {
                        SharedPtr<MessageInfo> messageInfo = messages->idx_get(i);
                        int attachmentCount = 0;
                        int64_t attachmentSize = 0;

                            SharedPtr<MapiAttachmentCollection> attachments = pst->ExtractAttachments(messageInfo);
                            attachmentCount = attachments->get_Count();

                            for (int j = 0; j < attachmentCount; j++) {
                                SharedPtr<MapiAttachment> att = attachments->idx_get(j);
                                attachmentSize += att->GetSize();
                            }
        } 
}
pst->Dispose();
pst = nullptr;
2

@Yu_Zhou

Cause

You are experiencing a memory leak when using the ExtractAttachments method to parse attachments from a PST file. This issue likely arises because the resources allocated for the attachments are not being properly released, even after calling the Dispose() method on the PersonalStorage object.

Solution

To resolve this issue, ensure that you are properly disposing of all resources related to the attachments. You need to explicitly dispose of the MapiAttachmentCollection and MapiAttachment objects after you are done using them.

Here’s a modified version of your code that includes proper disposal of the attachments:

Code

SharedPtr<PersonalStorage> pst = PersonalStorage::FromFile(pstFile, loadOptions);
SharedPtr<FolderInfo> root = pst->get_RootFolder();
SharedPtr<FolderInfoCollection> subFolders = root->GetSubFolders();
for (int i = 0; i < subFolders->get_Count(); i++) {
    SharedPtr<FolderInfo> folder = subFolders->idx_get(i);
    SharedPtr<MessageInfoCollection> messages = folder->GetContents();
    for (int j = 0; j < messages->get_Count(); j++) {
        SharedPtr<MessageInfo> messageInfo = messages->idx_get(j);
        SharedPtr<MapiAttachmentCollection> attachments = pst->ExtractAttachments(messageInfo);
        int attachmentCount = attachments->get_Count();
        int64_t attachmentSize = 0;

        for (int k = 0; k < attachmentCount; k++) {
            SharedPtr<MapiAttachment> att = attachments->idx_get(k);
            attachmentSize += att->GetSize();
            // Dispose of the attachment
            att->Dispose();
        }
        attachments->Dispose(); // Dispose of the collection
    }
}
pst->Dispose();
pst = nullptr;

Next Steps

  1. Implement the changes above to ensure that all resources are properly disposed of.
  2. Monitor the memory usage during the execution of your application to confirm that the issue is resolved.
  3. If the problem persists, investigate any other objects that may not be disposed of correctly.

Please let me know if you need further assistance!

3

Neither MapiAttachmentCollection nor MapiAttachment has the method Dispose().

4

Hello @Yu_Zhou,

We’ll investigate the issue and get back to you shortly.

5

Hello @Yu_Zhou,

We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): EMAILCPP-457

Thank you.

6

Could you please let us know the approximate time to fix these issues? This will help us better arrange for follow-up actions.

7

We are also encountering the same issue. Kindly inform us of the specific time when it will be fixed, as this will directly affect our procurement decision regarding this SDK.

8

The issue is planned to be fixed by the next release 25.7.