------- Comment #2 from random at adriver dot ru 2006-09-22 13:32 -------
(In reply to comment #1)
> The first "bug" simply doesn't exist given the comment at the beginning of
> __pool_base
In the beginning of __pool_base we see:
// Using short int as type for the binmap implies we are never
// caching blocks larger than 65535 with this allocator.
So, it says that I can cache blocks of up to 65535 bytes, while in reality
limit is 32768.
Code below will generate sigfault:
//
int main()
{
typedef __gnu_cxx::__mt_alloc<char> allocator_type;
typedef __gnu_cxx::__pool_base::_Tune tune_type;
//3.4: typedef __gnu_cxx::__mt_alloc<char>::_Tune tune_type;
allocator_type mt_char;
tune_type t(8, 50000, 8, (200000 - 4 * sizeof(void*)), 4096, 10, false);
mt_char._M_set_options(t);
allocator_type::pointer pc = mt_char.allocate(40000);
return 0;
}
_Binmap_type* __bp = _M_binmap;
_Binmap_type __bin_max = _M_options._M_min_bin; // not correct since you cast
size_t into u_short
//^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
_Binmap_type __bint = 0;
for (_Binmap_type __ct = 0; __ct <= _M_options._M_max_bytes; ++__ct)
{
if (__ct > __bin_max)
{
__bin_max <<= 1;
++__bint;
}
printf("__ct %d __bint %d __bin_max %d\n", __ct, __bint, __bin_max);
*__bp++ = __bint;
}
__ct 32757 __bint 12 __bin_max 32768
__ct 32758 __bint 12 __bin_max 32768
__ct 32759 __bint 12 __bin_max 32768
__ct 32760 __bint 12 __bin_max 32768
__ct 32761 __bint 12 __bin_max 32768
__ct 32762 __bint 12 __bin_max 32768
__ct 32763 __bint 12 __bin_max 32768
__ct 32764 __bint 12 __bin_max 32768
__ct 32765 __bint 12 __bin_max 32768
__ct 32766 __bint 12 __bin_max 32768
__ct 32767 __bint 12 __bin_max 32768
__ct 32768 __bint 12 __bin_max 32768
__ct 32769 __bint 13 __bin_max 0 // incorrect values start here
__ct 32770 __bint 14 __bin_max 0
__ct 32771 __bint 15 __bin_max 0
__ct 32772 __bint 16 __bin_max 0
__ct 32773 __bint 17 __bin_max 0
__ct 32774 __bint 18 __bin_max 0
__ct 32775 __bint 19 __bin_max 0
__ct 32776 __bint 20 __bin_max 0
__ct 32777 __bint 21 __bin_max 0
__ct 32778 __bint 22 __bin_max 0
__ct 32779 __bint 22 __bin_max 0
so we have incorrect binmap array.
> The second one is at most a documentation issue: _M_chunk_size
> shall be always much bigger than _M_max_bytes, thus __block_count always > 0.
would it not be easier to do a post increment and not have a problem with
people never reading documentation? especially considering that it's so easy to
fix?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29179
