Memory not released properly when using STEPCAFControl_Reader in Docker (ubuntu:build-24.04)

[ANPetrov-SysCon]

Description

Hello, I have a rather simple task of reading STEP file and sending it to another application (console application, cmake). The code was written using existing examples and works fine. With Windows there are no errors, all memory is released and VS profiler and ASAN shows no leaks. But when i build Docker and look at resources i see that after loading, transefering and processing is complete, the thread that was doing the job is finished, most of the memory is not released. Raised this issue before at: https://dev.opencascade.org/content/memory-not-released-properly-when-using-stepcafcontrolreader-docker-ubuntubuild-2404

Expected Behavior

Most part of memory release d after method is done, just as is done on windows (see screenshot from VS 2022 memory snapshot profiler for memory used. All of it released after stack unfolds)

Actual Behavior

Almost 900Mb for ~142 Mb file are lost on Linux

Sample Code or DRAW Tcl Script

bool loadStepFileTest(std::string STEPFile) {

    OSD_Parallel::SetUseOcctThreads(Standard_True);

    Handle(XCAFApp_Application) app = XCAFApp_Application::GetApplication();
    Handle(XCAFDoc_ShapeTool) shapeTool;
    Handle(XCAFDoc_ColorTool) colorTool;
    Handle(TDocStd_Document)  doc;
    app->NewDocument("MDTV-XCAF", doc);
    STEPCAFControl_Reader reader;
    IFSelect_ReturnStatus status = reader.ReadFile(STEPFile.c_str());
    if (status != IFSelect_RetDone) {
        std::cerr << "[ERROR] Error reading STEP-file: " << _savePath << std::endl;
        return false;
    }

    if (!reader.Transfer(doc)) {
        std::cerr << "[ERROR] Error in transferring data." << std::endl;
        return false;
    }
    shapeTool = XCAFDoc_DocumentTool::ShapeTool(doc->Main());
    colorTool = XCAFDoc_DocumentTool::ColorTool(doc->Main());

    if (shapeTool.IsNull() || colorTool.IsNull()) {
        std::cerr << "[ERROR] Could not acquire XDE tools." << std::endl;
        return false;
    }
    reader.ChangeReader().ClearShapes();
    reader.Reader().WS()->ClearData(1);
    reader.Reader().WS()->ClearContext();
    Handle(XSControl_WorkSession) aWS = reader.Reader().WS();
    if (Handle(XSControl_TransferReader) transferReader = aWS->TransferReader()) {
        if (Handle(Transfer_TransientProcess) mapReader = transferReader->TransientProcess()) {
            mapReader->Clear();
        }
        transferReader->Clear(-1);
    }
    if (!doc.IsNull()) {
        if (doc->HasOpenCommand())
        {
            doc->AbortCommand();
        }

        doc->Main().Root().ForgetAllAttributes(Standard_True);
        app->Close(doc);
        doc.Nullify();
    }
    return true;

}

Operating System

Linux

Compiler

GCC

Bitness

64-bit

OCCT Version

7.9

Additional Files

No response

[dpasukhi]

After internal investigation, we can't find any leaks in Ubuntu GCC version. All resources are free correctly with the provided code. At the moment, can't reproduce

[ANPetrov-SysCon]

@dpasukhi Ok, my bad not testing this code through. The bug reproduces for me when Handle(TDocStd_Document) doc is declared AND cleared outside of method. Didn't think to wrap test function in a test class and keep doc outside. Should i post this variant? UPD: Need further testing, someway behavior changed

[dpasukhi]

Closed. Can be reopen after updating of steps to reproduce.