pthread7-rope fails also for std::string :(

[Paolo Carlini <pcarlini at suse dot de>]

Hi everyone, hi Benjamin,

I'm looking a bit into the regression of pthread7-rope and unfortunately
I think it points to a serious problem in ~__pool.

The experimental evidence is that the testcase fails also with strings,
therefore is not related to (possible) rope memory leaks...

In order to debug a bit, I did a very trivial thing: added two printf, one
in __pool<true>::~__pool() and another in __pool<true>::_M_reclaim_block().

Then run pthread7-rope with only 1 thread (i.e., max_thread_count = 1) and
1 iteration (i.e., max_loop_count = 1): unfortunately suffices to have
a seg fault:

paolo:~/Work> g++ -O0 -g pthread7-rope.cc -lpthread
paolo:~/Work> a.out
In _M_reclaim_block, __thread_id = 1
In _M_reclaim_block, __thread_id = 1
In _M_reclaim_block, __thread_id = 1
In _M_reclaim_block, __thread_id = 1
In _M_reclaim_block, __thread_id = 1
In _M_reclaim_block, __thread_id = 1
In _M_reclaim_block, __thread_id = 1
In _M_reclaim_block, __thread_id = 1
Called ~__pool()
In _M_reclaim_block, __thread_id = 1076532124
Segmentation fault

Basically, what happens is that allocator code (_M_reclaim_block()) is
executed **after** ~__pool(), and, among other things going completely 
wrong,
_M_thread_freelist_initial is deleted, thus _M_get_thread_id() doesn't work
anymore (i.e., __thread_id = 1076532124).

As soon as ~__pool() is called and something else keeps going, either in the
current thread, or not (_M_address is shared among the threads!!), we are
running into **big** troubles, it seems...

Probably, I can debug the problem further later today.

Thanks for now,
Paolo.