From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24663 invoked by alias); 22 Sep 2006 13:32:17 -0000 Received: (qmail 24631 invoked by uid 48); 22 Sep 2006 13:32:07 -0000 Date: Fri, 22 Sep 2006 13:32:00 -0000 Message-ID: <20060922133207.24630.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/29179] bugs in mt_allocator In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "random at adriver dot ru" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-09/txt/msg02138.txt.bz2 List-Id: ------- 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, 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