Am 08.02.2018 um 10:14 schrieb Rainer Emrich:
> Am 08.02.2018 um 10:00 schrieb Rainer Emrich:
>> Am 06.02.2018 um 19:18 schrieb Jonathan Wakely:
>>> On 6 February 2018 at 18:03, Rainer Emrich wrote:
>>>
>>>> At least 20 of the acats tests catch all memory until the host memory is
>>>> exhausted.
>>>> Same holds for the two libstdc++ tests
>>>> 23_containers/unordered_set/requirements/exception/basic.cc
>>>> and
>>>> 23_containers/unordered_set/requirements/exception/propagation_consistent.cc
>>>
>>> Are these new failures? What changed? Where does it get stuck?
>>>
>>
>> Some of my observations, I don't know whats expected:
>>
>> In the function populate p(container_control)
>> "make_container_n<container_type> made(n);" is called with n=82.
>> This allocates nearly 16GByte on memory. Is this expected?
>>
>> Before the call to run_steps_to_limit(container_control, f) the
>> container_control structure has:
>> _M_bucket_count = 2019773507
>> _M_element_count = 82
>> _M_rehash_policy = {static _S_growth_factor = 2, _M_max_load_factor = 1,
>> _M_next_resize = 2019773507}
>>
>> To answer my own question, that's not expected. So at this state it's
>> already wrong.
>>
> Forgot to mention that's for
> 23_containers/unordered_set/requirements/exception/propagation_consistent.cc.
>
For 23_containers/unordered_set/requirements/exception/basic.cc the
situation is a little bit different. During the fifth invocation of
run_steps_to_limit(i, container, f) about 32 GByte are allocated.
Interesstingly the output seems right:
N10__gnu_test12functor_base12insert_pointISt13unordered_setIN9__gnu_cxx17throw_value_limitESt4hashIS4_ESt8equal_toIS4_ENS3_21throw_allocator_limitIS4_EEELb1ELb0EEE
end count 7
But the container structure is nonesense after the call:
_M_bucket_count = 4294967291
_M_element_count = 77
_M_rehash_policy = {static _S_growth_factor = 2, _M_max_load_factor = 1,
_M_next_resize = 18446744073709551615}
I hope that helps.
signature.asc
Description: OpenPGP digital signature
