scalable_malloc error

[uj]

I havea problem with allocating large arrays using new[].

This,

int

* p = new int[2032]; // 8128 bytes

works, but this,

int* p = new int[2033]; // 8128+4 bytes

does not. It throws a bad_alloc exception.

I read this in another thread at this forum:

"8K is the approximate size limit for requests that scalable_allocator serves from its own structures; for bigger requests, it refers to malloc"

So the problem seems related to when scalable_malloc uses malloc.

I'm using the pre-compiled binaries for VC++ 2008 in the tbb20_017oss download. I'm using theExpress edition.

I've replaced the new and delete functions according tothe Memory Allocation section in theTBB book and I've put traces in them so I know they're being called.

Another less severe problem is that the linker complains that the new/delete functions are already defined. Thisdoesn't seem to prevent it though from linking in the replacements.

There are also a few level 4 warnings in tbb ask.h.

[robert-reed]

Thanks for your observation. Have you posted anything about this at our TBB OSS bug tracking site? If not, could you take the time to do so? Thanks.

[uj]

I've reported it now. It's bug# 119.

[Alexey-Kukanov]

Thansk for reporting the issue. The fix for it is ready and will be available in the next developer update. Unfortunately I can't give you any promise about when it will be available in binary form. Also there should be no this problem in the previous com-aligned update, but that did not contain binaries for VS2008.

To avoid you being stuck due to the issue, I suggest you put errno=0; right before calling scalable_malloc in your operator new. You will also need to #include for the declaration of errno. Please let me know if it solves the problem for you.

uj:

Another less severe problem is that the linker complains that the new/delete functions are already defined. Thisdoesn't seem to prevent it though from linking in the replacements.

The linker complains because you replace global new and delete operators which are also defined in the C/C++ runtime library. Honestly, I think it should not, because in the C++ standard it is clearly specified that:

A C + + program may provide the definition for any of eight dynamic memory allocation function signatures declared in header ... The programs definitions are used instead of the default versions supplied by the implementation.

I have already heard of similar problems before (e.g. in an earlier thread) but was not able to reproduce it by myself.

uj:

There are also a few level 4 warnings in tbb ask.h.

We believe that satisfaction of any compiler warning is bad, especially for a cross-platform library such as TBB. Every new release of a compiler brings new warnings that they think are smart and useful. And we have already put enough strange code-obfuscating constructswhich sole purpose is to shut down this or that warning.So we selected level 3 as the reasonable limit, and we'll ensure TBB public headers are free of level 3 and above warnings. As for level 4 warnings, we do not care and won't spend time and efforts on shutting those (I deliberately do not say "fixing" because there isno issuethat should be fixed).

[uj]

MADakukanov:

To avoid you being stuck due to the issue, I suggest you put errno=0; right before calling scalable_malloc in your operator new.

Thank you that solved the main problem.

The linker problemcomes and goes in mysterious ways. The linker even hangs occasionally. There are different work-arounds on the internet but I've foundthat it seems related to incremental linking, so I've switchedthat off.

Well, warning level 3 seems to be established as sufficient and even Boost has level 4 warnings. My solution is to lower the warning level for such header files.