scalable_malloc memory corruption

[Blue_Sky_Studios]

I have a program that uses a lot of threads (56) and a lot of memory (> 300 GB).  When I run an optimized version, it dies with a bad_alloc exception, although there should be about 200 GB still available (physical memory + some swap space).  When I run a debug version, it hits this assertion failure:

Assertion !freeObj->next || ((uintptr_t)freeObj->next > (uintptr_t)currBlock && (uintptr_t)freeObj->next < (uintptr_t)currBlock + slabSize) failed on line 308 of file ../../src/tbbmalloc/backref.cpp

I upgraded from TBB 4.3 update 6 to TBB 4.4 update 3, and the behavior is the same.

I suspect my program is freeing an already freed block of memory.  Is that what the assertion might indicate?

Is there any way to detect corruption in the use of scalable_malloc?

[Alexandr_K_Intel1]

Is it Windows or Linux?

I suspect my program is freeing an already freed block of memory.  Is that what the assertion might indicate?

The assertion was written against generic memory overrun, straightforward double frees are supposed to be addressed elsewhere. But sure, it’s hard to predict consequence of access to released memory.

Is there any way to detect corruption in the use of scalable_malloc?

Intel Inspector XE has scalable_malloc support and detects double free. Sometimes I use concurrent_hashmap as a light-weight aid for that.

[Blue_Sky_Studios]

It is Linux -- CentOS 6.7.  I have compiled everything with Clang 3.5 using gcc 4.8.3 as the toolchain.

I tried rebuilding without using scalable_malloc for operator new.  The optimized version gave a successful run using a maximum of about 200 GB.  I started a TotalView memory checking run (lowest level, should detect memory corruption) on Friday, but it is still going.  It just has a slew of heap allocations and de-allocations.  If it finishes, it should convince me that the application is not causing memory corruption, but I may give up on it.

I will try the Inspector with the scalable_malloc version next.