This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [v3] libstdc++/24469
On 3/16/06, Richard Guenther <richard.guenther@gmail.com> wrote:
> On 3/16/06, Paolo Carlini <pcarlini@suse.de> wrote:
> > Richard Guenther wrote:
> >
> > >yes, I did study the PR in question (24469), but even from reading
> > >http://gcc.gnu.org/ml/libstdc++/2004-07/msg00095.html I cannot reproduce the
> > >failure in question by examining the source (I cannot find users of _M_thread_id
> > >in either mt_allocator.cc or mt_allocator.h apart from two setters on
> > >the v7 branch).
> > >
> > >
> > Please look closer ;) (Considering mainline, for the moment) just grep
> > for the various places where ._M_used[*] is changed. The point is simply
> > that in one specific place, in _M_reclaim_block, the index is
> > __block->_M_thread_id, which in general is != __thread_id, thus we are
> > fiddling with another thread, not the one which is returning memory to
> > the pool.
>
> Sure - I specifically looked at v7 branch because Benjamins patch was for v7,
> especially _not_ v3. And in v7, _M_thread_id is only set, not read.
> My argument is
> that for v7(!) branch, the patch is not necessary. I did not look in
> detail at v3 branch,
> but I will do so now (before just posting an extrapolation of the v7
> analysis...)
It looks like that for v7 branch we get out of the problem v3 is in by
simply accounting
_M_used to possibly the wrong bin in case allocate/deallocate are from different
threads. But I'll chime out now and let you folks resolve the issue
that might be left
on v3/v7, because you know what you are doing appearantly.
Richard.