Calling the .eql? and .hash methods during a Hash operation can
result in a thread switch or a signal handler to run: allowing
one execution context to rebuild the hash table while another is
still reading or writing the table.  This results in a
use-after-free bug affecting the thread_safe-0.3.6 test suite
and likely other bugs.

This bug did not affect users of commonly keys (String, Symbol,
Fixnum) as those are optimized to avoid method dispatch
for .eql? and .hash methods.

A separate version of this change needs to be ported to Ruby 2.3.x
which had a different implementation of st.c but was affected
by the same bug.

* st.c: Add comment about table rebuilding during comparison.
  (DO_PTR_EQUAL_CHECK): New macro.
  (REBUILT_TABLE_ENTRY_IND, REBUILT_TABLE_BIN_IND): New macros.
  (find_entry, find_table_entry_ind, find_table_bin_ind): Use new
  macros.  Return the rebuild flag.
  (find_table_bin_ptr_and_reserve): Ditto.
  (st_lookup, st_get_key, st_insert, st_insert2): Retry the
  operation if the table was rebuilt.
  (st_general_delete, st_shift, st_update, st_general_foreach):
  Ditto.
  (st_rehash_linear, st_rehash_indexed): Use DO_PTR_EQUAL_CHECK.
  Return the rebuild flag.
  (st_rehash): Retry the operation if the table was rebuilt.
  [ruby-core:85510] [Ruby trunk Bug#14357]

Thanks to Vit Ondruch for reporting the bug.

From: Vladimir Makarov <vmakarov@redhat.com>

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62396 b2dd03c8-39d4-4d8f-98ff-823fe69b080e