[Bug c++/29179] New: bugs in mt_allocator
This example will demonstrate 2 problems in mt_allocator.cc:
typedef __gnu_cxx::__mt_alloc allocator_type;
typedef __gnu_cxx::__pool_base::_Tune tune_type;
allocator_type mt_char;
tune_type t(8, 4, 8, (5 - 4 * sizeof(void*)), 4096, 10, false);
mt_char._M_set_options(t);
allocator_type::pointer pc = mt_char.allocate(4);
First bug in __pool<..>::_M_initialize():
Binmap_type __bin_max = _M_options._M_min_bin; // not correct.
size_t __bin_max = _M_options._M_min_bin; // correct.
Second bug in __pool<..>::_M_reserve_block():
while (--__block_count > 0) // not correct because __block_count may be equal
0(and size_t is unsigned)
{
__c += __bin_size;
__block->_M_next = reinterpret_cast<_Block_record*>(__c);
__block = __block->_M_next;
}
while (__block_count > 0) // correct
{
__c += __bin_size;
__block->_M_next = reinterpret_cast<_Block_record*>(__c);
__block = __block->_M_next;
--__block_count;
}
--
Summary: bugs in mt_allocator
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: random at adriver dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29179
[Bug libstdc++/29179] bugs in mt_allocator
--- 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 allocator_type;
typedef __gnu_cxx::__pool_base::_Tune tune_type;
//3.4: typedef __gnu_cxx::__mt_alloc::_Tune tune_type;
allocator_type mt_char;
tune_type t(8, 5, 8, (20 - 4 * sizeof(void*)), 4096, 10, false);
mt_char._M_set_options(t);
allocator_type::pointer pc = mt_char.allocate(4);
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
[Bug libstdc++/29179] bugs in mt_allocator
--- Comment #4 from random at adriver dot ru 2006-09-22 14:40 --- (In reply to comment #3) > No, for the simple reason that the allocator does not work is __block_count > turns out to be zero. The problem with your PR is that you are doing sort of > syntactical analysis of the code without understandind the functioning of the > allocator. ok, perhaps this is not really a bug, however segfault is not very user friendly. could ASSERT solve it? about the first one, I take it you agree that it is a real bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29179
[Bug c++/54972] New: O2 breaks something in 4.6.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54972 Bug #: 54972 Summary: O2 breaks something in 4.6.3 Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ran...@adriver.ru Created attachment 28480 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28480 .ii file compiling lzo_gcc_test.cpp with parameters: g++ -o lzo lzo_gcc_test.cpp -llzo2 running binary produces: rv= 0 uncompressed size= 73 UNC2: 'This is uncompressed zzz', as expected. adding -O2 to parameters results in rv= 0 uncompressed size= 73 UNC2: '', at this point UNC2 contains rubbish
[Bug c++/54972] O2 breaks something in 4.6.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54972 --- Comment #3 from Seva Potapov 2012-10-18 11:46:19 UTC --- thanks for input guys, but for some reason I don't get same warnings as you: $ g++-4.6 -Wall -Wextra lzo_gcc_test.cpp -llzo2 lzo_gcc_test.cpp:27:5: warning: unused parameter ‘argc’ [-Wunused-parameter] lzo_gcc_test.cpp:27:5: warning: unused parameter ‘argv’ [-Wunused-parameter] $ g++-4.6 -v Using built-in specs. COLLECT_GCC=g++-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
[Bug c++/54972] O2 breaks something in 4.6.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54972 --- Comment #6 from Seva Potapov 2012-10-18 12:07:40 UTC --- thanks, guys, it seems that -Wstrict-aliasing=2 is not part of -Wall or -Wextra i'll keep that in mind next time I encounter "bug" with gcc :)
