From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5051 invoked by alias); 9 Sep 2005 08:26:25 -0000 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 Received: (qmail 5027 invoked by uid 48); 9 Sep 2005 08:26:20 -0000 Date: Fri, 09 Sep 2005 08:26:00 -0000 Message-ID: <20050909082620.5025.qmail@sourceware.org> From: "jakub at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050705135434.22309.jakub@redhat.com> References: <20050705135434.22309.jakub@redhat.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libstdc++/22309] mt allocator doesn't pthread_key_delete it's keys X-Bugzilla-Reason: CC X-SW-Source: 2005-09/txt/msg01081.txt.bz2 List-Id: ------- Additional Comments From jakub at gcc dot gnu dot org 2005-09-09 08:26 ------- Without init_priority, how can you be sure that other libstdc++.so destructors will not be run after __gnu_internal::freelist is destructed? If there are some destructors and they use the mt allocator (whether to allocate some temporary memory or more likely to free some memory), won't it cause big problems? As for the lock being static, mt-allocator.cc is the only user of that lock, so I don't see why it should be externally visible, even if just in libstdc++.a (in libstdc++.so symbol versioning will hide it). If there are other locks used solely in one .cc file, I think they should be made static too. Thanks for writing the testcase. Haven't tried to compile your latest patch yet, do the changes preserve ABI compatibility? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309