[Bug libstdc++/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc

["ubizjak at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #21 from ubizjak at gmail dot com  2009-08-31 06:52 -------
(In reply to comment #20)

> > Sigh, the patch doesn't fix alpha failure :(
> 
> It also doensn't fix reliably the failure on i?86.  Is your alpha
> failure on lto branch or on trunk?

It is on the trunk. However, I have started debugging this, and the problem is
that the pointer to LSDA structure gets corrupted and test aborts when parsing
LSDA header with parse_lsda_header. The actual abort is triggered in
read_encoded_value_with_base.

Exception data points to
_ZN10__gnu_pbds6detail15gp_ht_map_data_INS_4test10basic_typeES3_NS2_4hashESt8equal_toIS3_EN9__gnu_cxx15throw_allocatorIS3_EELb0ENS2_27direct_mod_range_hashing_t_IS9_EENS2_21quadratic_probe_fn_t_IS3_S9_EENS_27hash_standard_resize_policyINS2_25hash_prime_size_policy_t_ENS2_33hash_load_check_resize_trigger_t_IS9_Lm1ELm8ELm1ELm2ELb1EEELb1EmEEEC2ERKSJ_

aka:

__gnu_pbds::detail::gp_ht_map_data_<__gnu_pbds::test::basic_type,
__gnu_pbds::test::basic_type, __gnu_pbds::test::hash,
std::equal_to<__gnu_pbds::test::basic_type>,
__gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type>, false,
__gnu_pbds::test::direct_mod_range_hashing_t_<__gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type>
>, __gnu_pbds::test::quadratic_probe_fn_t_<__gnu_pbds::test::basic_type,
__gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> >,
__gnu_pbds::hash_standard_resize_policy<__gnu_pbds::test::hash_prime_size_policy_t_,
__gnu_pbds::test::hash_load_check_resize_trigger_t_<__gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type>,
1ul, 8ul, 1ul, 2ul, true>, true, unsigned long>
>::gp_ht_map_data_(__gnu_pbds::detail::gp_ht_map_data_<__gnu_pbds::test::basic_type,
__gnu_pbds::test::basic_type, __gnu_pbds::test::hash,
std::equal_to<__gnu_pbds::test::basic_type>,
__gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type>, false,
__gnu_pbds::test::direct_mod_range_hashing_t_<__gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type>
>, __gnu_pbds::test::quadratic_probe_fn_t_<__gnu_pbds::test::basic_type,
__gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> >,
__gnu_pbds::hash_standard_resize_policy<__gnu_pbds::test::hash_prime_size_policy_t_,
__gnu_pbds::test::hash_load_check_resize_trigger_t_<__gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type>,
1ul, 8ul, 1ul, 2ul, true>, true, unsigned long> > const&)

Defined in:

file
/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/include/ext/pb_ds/detail/gp_hash_table_map_/constructor_destructor_fn_imps.hpp,
line 144. (2 locations)

Return address points just after the call to:

   12000f9e8:   d3 da 5f d3     bsr     ra,120006538
<_ZN9__gnu_cxx16probability_base19throw_conditionallyEv+0x8>
>  12000f9ec:	00 00 fe 2f 	unop	
   12000f9f0:   00 00 fe 2f     unop    

This is hard to debug, since this is conditional exception, and the condition
that triggers this exception depends on a random value.

I have checked that it is not LSDA data that gets corrupted, but the pointer to
LSDA data:

failed: 0x1201bb405

objdump --section=.gcc_except_table -s hash_data_map_rand.test

 1201bb3f4 ff9b2d01 23a80148 c40400f0 0208b404  ..-.#..H........
>1201bb404 01880308 e00301d8 0304c404 009c0414  ................
 1201bb414 e80400e0 04040000 01000000 00000000  ................
 1201bb424 ff9b2101 17ac0208 d80401d8 0308fc03  ..!.............
 1201bb434 05940404 a80400d0 04380000 7f000000  .........8......
 1201bb444 7f7d0000 00000000 ff9b4901 41d4015c  .}........I.A..\

correct: 0x1201bb3f4

 1201bb3e4 00ffff01 08240848 005c0400 00000000  .....$.H.\......
>1201bb3f4 ff9b2d01 23a80148 c40400f0 0208b404  ..-.#..H........
 1201bb404 01880308 e00301d8 0304c404 009c0414  ................
 1201bb414 e80400e0 04040000 01000000 00000000  ................
 1201bb424 ff9b2101 17ac0208 d80401d8 0308fc03  ..!.............
 1201bb434 05940404 a80400d0 04380000 7f000000  .........8......

So, the pointer to LSDA is off by 0x11.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058