View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0030757Open CASCADEOCCT:Foundation Classespublic2019-05-30 10:462023-08-01 15:08
ReporterszyAssigned Toabv 
PrioritynormalSeverityminor 
Status assignedResolutionopen 
PlatformWindowsOSVC++ 2015 
Product Version7.3.0 
Target VersionUnscheduled 
Summary0030757: Memory leaks using Open CasCade with TBB
DescriptionThe customer complaint is below:
"We have found that there are memory leaks in OpenCascade.
It seems that most of the leaks are related the use of TBB (Intel® Threading Building Blocks), which is an optional component.
We tried out that not using TBB solves the related memory leak problems, and the speed of execution was just slightly affected."

Configuration used: Windows 10 & VStudio 2015 & 64 bit.

The delivered sample gives the next output:

"Detected memory leaks!
Dumping objects ->
{13589} normal block at 0x000001D51BA746A0, 520 bytes long.
 Data: < p > 04 00 00 00 00 00 00 00 70 7F 89 1D D5 01 00 00
{13588} normal block at 0x000001D51BA2F910, 520 bytes long.
 Data: < > 04 00 00 00 00 00 00 00 B0 7F 89 1D D5 01 00 00
{13587} normal block at 0x000001D51BA29740, 520 bytes long.
 Data: < > 04 00 00 00 00 00 00 00 F0 7F 89 1D D5 01 00 00
{173} normal block at 0x000001D51BA19550, 16 bytes long.
 Data: < * > A8 F3 2A FC FD 7F 00 00 01 CD CD CD CD CD CD CD
Object dump complete.
The program '[21000] LeakageExample.exe' has exited with code 0 (0x0).
"
The archive LeakageExampleV4.zip(~ 90 MB) is available at \\SZY\SHARE\BIMO folder.
Steps To Reproduce1.Explode archive
2.Open "LeakageExample.sln" with VStudio 2015
3.Build it
4.Start application: menu "Debug/Start Debugging"

Output reports:
"Detected memory leaks!"
TagsNo tags attached.
Test case number

Activities

kgv

2019-06-05 09:19

developer   ~0084839

Last edited: 2019-06-05 09:19

 Sergey, could you please comment if customer's application actually suffers from severe memory leaks (e.g. leading to continuous grow of memory usage of noticeable amounts),
or just observed some memory flows detected by runtime memory analyzer?

szy

2019-06-18 10:11

manager   ~0085108

The customer's feedback is below:

"I have seen that the developers had questions regarding the issue
0030757: Memory leaks using Open CasCade


I'd like to confirm that the TBB leak caused a substantial amount of memory leak.
Would also give some additional information that might have remained hidden:

In the example project that demonstrates the leak, at
// DetectionHelper.cpp:
...
#if defined (MEMORY_LEAK_HUNTING)
class MemCheck {
public:
 MemCheck()
 {
  _CrtSetDbgFlag (_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
  _CrtSetBreakAlloc(0); //This is (the latest is) the effective number
  // You can set a watch for
  // {,,ucrtbased.dll}__acrt_current_request_number
  // and
  // {,,ucrtbased.dll}_crtBreakAlloc
  // in the watch window, to check or modify these values
  // during a debug session.
 }
};
MemCheck memCheck;
#endif
you can set a break point to a given leak, if it i's occuring in a deterministic way.
For example if you get the
"Detected memory leaks!
 Dumping objects ->
 {13589} normal block at 0x000001D51BA746A0, 520 bytes long.
  Data: < p > 04 00 00 00 00 00 00 00 70 7F 89 1D D5 01 00 00
 {13588} normal block at 0x000001D51BA2F910, 520 bytes long.
  Data: < > 04 00 00 00 00 00 00 00 B0 7F 89 1D D5 01 00 00
 {13587} normal block at 0x000001D51BA29740, 520 bytes long.
  Data: < > 04 00 00 00 00 00 00 00 F0 7F 89 1D D5 01 00 00
 {173} normal block at 0x000001D51BA19550, 16 bytes long.
  Data: < * > A8 F3 2A FC FD 7F 00 00 01 CD CD CD CD CD CD CD
 Object dump complete.
message, then you should change the
  _CrtSetBreakAlloc(0); //This is (the latest is) the effective number
line to
  _CrtSetBreakAlloc(173); //This is (the latest is) the effective number
to have a break point at the allocation which hasn't the corresponding delete/free operation.
after teh break point reached you can examine the call stack, and can set the next one using a watch window
and the
 {,,ucrtbased.dll}_crtBreakAlloc
variable can be set to the next value, e. g. to 13587"

msv

2019-06-18 10:24

developer   ~0085109

I'd like to say that in the most such "Detected memory leaks!" cases the leaked object is just a global static variable. There are a lot of such static objects when you use OCCT libraries.

So, in order to prove that it is a real leak it is needed to write a piece of code in a loop, in which each new iteration must start from scratch, and at the end return all memory to the system. If during repeating the loop we will see increase of used by app memory then it is a real leak that can be detected and healed. Otherwise, I do not see any reason to work under the problem that is really absent.

abv

2019-07-11 09:05

manager   ~0085581

Please note that TBB is known to use its own optimized memory manager that does not return unused blocks of memory to the system but reuses them, to increase performance. For this reason some memory can be held by TBB even after the processing is completed. Thus this does not look like a real memory leak.

If the reporter insists on presence of the leak, a reproducer is needed (I cannot access the archive mentioned). As Mikhail explained in previous comment, memory leak can be shown by demonstrating that repetitive actions that are not expected to accumulate data objects do lead to constant increase of memory consumption.

Otherwise please close the issue.

szy

2019-07-19 16:05

manager   ~0085794

Andrey,
I have added access to the archive for you (see \\SZY\SHARE\BIMO).

szy

2019-07-19 16:06

manager   ~0085795

Access is provided.

Issue History

Date Modified Username Field Change
2019-05-30 10:46 szy New Issue
2019-05-30 10:46 szy Assigned To => msv
2019-05-31 10:09 msv Description Updated
2019-06-05 09:19 kgv Note Added: 0084839
2019-06-05 09:19 kgv Note Edited: 0084839
2019-06-18 10:11 szy Note Added: 0085108
2019-06-18 10:12 szy Category OCCT:Modeling Algorithms => OCCT:Foundation Classes
2019-06-18 10:24 msv Note Added: 0085109
2019-06-24 08:53 kgv Summary Memory leaks using Open CasCade => Memory leaks using Open CasCade with TBB
2019-07-11 09:05 abv Note Added: 0085581
2019-07-11 09:05 abv Assigned To msv => szy
2019-07-11 09:05 abv Status new => feedback
2019-07-19 16:05 szy Note Added: 0085794
2019-07-19 16:06 szy Note Added: 0085795
2019-07-19 16:06 szy Assigned To szy => abv
2019-07-19 16:06 szy Status feedback => assigned
2019-08-13 12:04 kgv Target Version 7.4.0 => 7.5.0
2020-09-11 16:13 utverdov Target Version 7.5.0 => 7.6.0
2021-09-20 08:48 kgv Target Version 7.6.0 => 7.7.0
2022-10-24 10:40 szy Target Version 7.7.0 => 7.8.0
2023-08-01 15:08 dpasukhi Target Version 7.8.0 => Unscheduled