Issues with switching base allocator in so 6 inside attachment.
Created attachment 8666 [details] bug
Created attachment 8667 [details] revert base allocator change
Additional fixes include adding _M_reclaim_block checks. However, this seems to be patching the symptom, not the disease.
Ick! :( Actually, I clearly remember a message from Mark warning that something could go wrong when using different allocators in different sources, but then forgot about the issue when we switched. I really hope that we can work around it, somehow...
While 4.0 had this fixed, trunk still uses the 'mt' allocator by default on linux, and hence is incompatible with 3.4 and 4.0 by default. Is that really intended, or shouldn't also trunk default back to the 'new' allocator?
In general, we make no claims as to ABI compliance wrt development/trunk versions.
Of course not. But unaware people trying trunk currently on distros which provided 3.4 or 4.0 will get non-obvious problems, and I'm not sure if that's a good idea (ignoring this problem 4.0 and trunk are nearly compatible, and 4.0 compiled programs work with the trunk libstc++, which has the same SOname like the 4.0 one). I think the only way to switch to the 'mt' allocator by default for the future without API issues would be to rename it to 'new', and not via some configure arguments. Another reason is that this switching back of the default allocator is not forgotten when 4.1 branches, which I think is necessary anyway, so that 4.1 libs are compatible with 4.0 programs.
We'd certainly not forget about this on the branch. However, I decided to just go ahead and do this anyway, because it is a change in behavior but mostly because it seems to be confusing people/distros WRT what allocator choices should be standard.
No open issues.