Memory corruption in scalable_allocator

Memory corruption in scalable_allocator

I am currently using TBB 4.4 Update 5 and I am seeing some crashes in our environment and most of the dumps that are generated point to scalable_malloc failing but I am not sure whether there is a bug in our code or in that of TBB. I saw the release notes for Update 6 and it mentions that some bug regarding memory corruption was fixed. Is there any way to know what is the bug that was fixed or what evidence I can look for in the dumps which will point me to identify if this was caused by the bug in TBB. 


Thread Topic: 

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.


You can get difference between releases in sources on the github project page

Could you please try to reproduce it with new version of library

I have looked at the diff between 4.4 U5 and 4.4 U6 but it is not clear to me how changing the padding will prevent memory corruption in x64 architecture. It would be good to know the nature/symptoms of the corruption issue that was fixed.

I am going to upgrade the TBB libraries to the latest release but it will take a while to get it into production where we are currently seeing this issue. So it would be good to know whether or not we should be looking for potential issues in our code.

Hi Ritwik,

indeed changing the padding has nothing to do with fixing crashes/corruption :)

We had an issue in 4.4.5 and earlier if all the space in our internal "back reference" tables is exhausted. You might encounter it if you allocate 256 GB or more (but it depends on the number of allocated blocks, not the total size). In 4.4.6, the issue was fixed; the correspondent changes are in BackRefMaster::requestNewSpace() method if you are curious.

Leave a Comment

Please sign in to add a comment. Not a member? Join today