Ruby Issue Tracking System: Issueshttps://redmine.ruby-lang.org/https://redmine.ruby-lang.org/favicon.ico?17113305112014-09-23T11:29:30ZRuby Issue Tracking System
Redmine Ruby master - Bug #10285 (Closed): StringIO with encodings broken due to #9769https://redmine.ruby-lang.org/issues/102852014-09-23T11:29:30Zdbussink (Dirkjan Bussink)d.bussink@gmail.com
<p>It looks like the change in <a href="https://bugs.ruby-lang.org/issues/9769" class="external">https://bugs.ruby-lang.org/issues/9769</a> resulted in a behavior change with how StringIO works with different encodings.</p>
<p>The following snippet is broken and now raises:</p>
<pre><code>test_string_io_encoding.rb:8:in `write': incompatible character encodings: ASCII-8BIT and Windows-1252 (Encoding::CompatibilityError)
from test_string_io_encoding.rb:8:in `<main>'
</code></pre>
<pre><code>require 'stringio'
io = StringIO.new
io.set_encoding(Encoding::ASCII_8BIT)
io.write("quz \x83 mat".force_encoding(Encoding::ASCII_8BIT))
str = "foo \x97 bar".force_encoding(Encoding::WINDOWS_1252)
io.write(str)
p io.string
</code></pre>
<p>What is the intended behavior here? If I change the code to not set the encoding on the StringIO object, it does work somehow:</p>
<pre><code>require 'stringio'
io = StringIO.new
io.write("quz \x83 mat".force_encoding(Encoding::ASCII_8BIT))
str = "foo \x97 bar".force_encoding(Encoding::WINDOWS_1252)
io.write(str)
p io.string
</code></pre>
<p>In this case it sees io.string as UTF-8 encoded, but this is invalid. It does allow the second StringIO#write here though.</p> Ruby master - Bug #8399 (Closed): Remove usage of RARRAY_PTR in C extensions when not neededhttps://redmine.ruby-lang.org/issues/83992013-05-13T05:37:02Zdbussink (Dirkjan Bussink)d.bussink@gmail.com
<p>Rubinius uses quite a few C extensions directly from MRI. Some of these use functionality such as RARRAY_PTR which is not necessary. For compatibility reasons, RARRAY_PTR works on Rubinius but suffers from a heavy performance penalty. Take for example the test of the parser gem (<a href="http://github.com/whitequark/parser" class="external">http://github.com/whitequark/parser</a>). These run over 10x faster with the patch applied to Racc that is submitted here:</p>
<p><a href="https://gist.github.com/dbussink/57c32c08fb21c7a41719" class="external">https://gist.github.com/dbussink/57c32c08fb21c7a41719</a></p>
<p>Consider issue <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Introducing Geneartional Garbage Collection for CRuby/MRI (Closed)" href="https://redmine.ruby-lang.org/issues/8339">#8339</a> where there is work being done on generational GC, I think it is also beneficial to remove usage of internal structures such as RARRAY_PTR where there is the problem of going around the write barrier. In Rubinius, an array is treated special if RARRAY_PTR is used on it in the C-API, so I can imagine MRI being able to optimize the GC better if extensions don't do this. There are functions available for both getting and setting elements in an array and they work fine.</p>
<p>I have only make a patch against Racc here as a showcase, I also want to update all the other extensions to remove RARRAY_PTR. Please consider this change to MRI since in my opinion it has benefits also for MRI and so Rubinius can keep using these extensions directly without having to maintain custom versions just for the considerations described here. I'm also already actively checking C extension gems and sending pull requests for updating this.</p> Ruby master - Bug #8386 (Closed): OpenSSL thread safetyhttps://redmine.ruby-lang.org/issues/83862013-05-10T20:11:39Zdbussink (Dirkjan Bussink)d.bussink@gmail.com
<p>As some might know, Rubinius uses a lot of MRI's C extensions that are part of stdlib and ships them as well. Rubinius however does not have a GIL, so thread safety issues in C extensions are much more important.</p>
<p>This patch fixes a thread safety issue in the OpenSSL extension, to allow for it being used in a concurrent scenario. This follows from the documentation of OpenSSL:</p>
<ol>
<li>Is OpenSSL thread-safe?</li>
</ol>
<p>Yes (with limitations: an SSL connection may not concurrently be used by multiple threads). On Windows and many Unix systems, OpenSSL automatically uses the multi-threaded versions of the standard libraries. If your platform is not one of these, consult the INSTALL file.</p>
<p>Multi-threaded applications must provide two callback functions to OpenSSL by calling CRYPTO_set_locking_callback() and CRYPTO_set_id_callback(), for all versions of OpenSSL up to and including 0.9.8[abc...]. As of version 1.0.0, CRYPTO_set_id_callback() and associated APIs are deprecated by CRYPTO_THREADID_set_callback() and friends. This is described in the threads(3) manpage.</p>
<p>This patch adds using the callback and thread_id functions so this works properly with Rubinius. This issue is not just theoretical, I've been able to reproduce crashes when using OpenSSL in different threads that have been fixed by this change. Rubinius already incorporated the change, but preferable I would not have to maintain a custom fork with these changes, but be able to use the MRI version without changes. I've already discussed the change with Martin and he saw no reason for objecting this change.</p> Ruby master - Bug #6821 (Closed): GC::Profiler.enabled? returns 0 when enabledhttps://redmine.ruby-lang.org/issues/68212012-08-02T06:24:14Zdbussink (Dirkjan Bussink)d.bussink@gmail.com
<p>GC::Profiler.enabled? returns 0 when GC::Profiler is enabled, contrary to the documentation that states it returns either true or false. Looking at the code, I think it's an oversight because objspace->profile.run isn't properly wrapped for a VALUE. So TRUE is returned, which is 1 as a VALUE which equals the value for the Fixnum 0.</p>
<p>This changeset should fix the problem:</p>
<p><a href="https://gist.github.com/9fe02bd47515cbbcced7" class="external">https://gist.github.com/9fe02bd47515cbbcced7</a></p>