vmakarov / redhat.com wrote:
> File thread-table-rebuild.patch added

Thank you for working on this!

>   This problem results in ICE for new hash tables.  For old hash
> tables, the problem would have corrupted hash table structure which
> probably results in later incorrect table behaviour.

ICE - Internal Compiler Error?  Or did you mean "use-after-free"?

Yes, 2.3 and earlier st.c is affected by this, too, just seems
to hit less frequently...  2.3 maintainer(s) will need to
backport from scratch, maybe

<snip>

> I have no write access to Ruby repository.  So please, consider the
> patch for inclusion into the trunk.

Looks good to me, committed as r62396.
You can probably ask hsbt and matz for commit access.

> I cannot find where changelog entry should go for the current trunk,
> but here it is.

We write changelog entries in the commit message nowadays.  In the
future, you can send the output of "git format-patch" since it
appears you're using git anyways and we can "git am" it.

I also wrote the following text to summarize in r62396

    st.c: retry operations if rebuilt

    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.

(and copied your changelog entry below)

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>