[MacRuby] #215: OpenSSL's SSLSocket appears not to be initialised correctly
#215: OpenSSL's SSLSocket appears not to be initialised correctly -------------------------------+-------------------------------------------- Reporter: celtic@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: openssl -------------------------------+-------------------------------------------- When using net/https, the line to create the new SSLSocket in `connect' fails in OpenSSL::SSL::Nonblock, trying to call @io.fcntl and failing since @io==nil. @io should be being set in OpenSSL's ossl_ssl.c:ossl_ssl_initialize; "ossl_ssl_set_io(self, io)"; but this function appears never to be called! (I tried inserting various rb_warns throughout, before finally just sticking in a call to exit() -- it's not being touched) This appears to be the only place where @io is being set. It disturbs me that the C initialiser is not being run - I am not sure if this is a documented issue or not, or if it's even a MacRuby bug (I'm quite new to all this). This problem can be 'fixed' in the meantime by rewriting SSLSocket#initialize in Ruby-land: {{{ def initialize io, ctx=nil ctx = SSLContext.new if ctx.nil? raise "wrong argument (#{ctx.class})! (Expected kind of SSLContext)" if not ctx.kind_of? SSLContext raise "wrong argument (#{io.class})! (Expected kind of IO)" if not io.kind_of? IO @io, @ctx = io, ctx @sync_close = false @ctx.setup super end }}} ossl_ssl_initialize can be removed from ossl_ssl.c after this. Unfortunately, we just run into another bug in ossl_ssl_setup, which has to do with an SSLContext, trying to work out if it's related now. -- Ticket URL: <http://www.macruby.org/trac/ticket/215> MacRuby <http://macruby.org/>
#215: OpenSSL's SSLSocket appears not to be initialised correctly -------------------------------+-------------------------------------------- Reporter: celtic@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: openssl -------------------------------+-------------------------------------------- Comment(by celtic@…): My mistake, those references to '''@ctx''' above should be '''@context'''. Why we call it context in instance variables and ctx everywhere else, I'll never know... -- Ticket URL: <http://www.macruby.org/trac/ticket/215#comment:1> MacRuby <http://macruby.org/>
#215: OpenSSL's SSLSocket appears not to be initialised correctly -------------------------------+-------------------------------------------- Reporter: celtic@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: openssl -------------------------------+-------------------------------------------- Comment(by celtic@…): Unfortunately, we now just get a bug like this somewhere in SSLSocket#connect now: {{{ /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/net/http.rb:606: [BUG] destination 0x7fff5fbfe2e8 isn't in the auto zone }}} Unrelated to the above issue, however. -- Ticket URL: <http://www.macruby.org/trac/ticket/215#comment:2> MacRuby <http://macruby.org/>
#215: OpenSSL's SSLSocket appears not to be initialised correctly -------------------------------+-------------------------------------------- Reporter: celtic@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: openssl -------------------------------+-------------------------------------------- Comment(by celtic@…): The issue causing the bug was due to '''rb_fdset_t'''s being allocated on the stack in '''rb_io_wait_readable'''. It appeared Ruby's autozone thing had a fit. I notice this was discussed in #160. I'm attached a diff for fixing this and OpenSSL's issues: 1. '''rb_io_wait_readable''' and '''rb_io_wait_writable''' (for completeness) now allocate their fdsets on the heap (fixes autozone bug) 2. '''SSLSocket#initialize''' is moved to Ruby code (but where to put the rdoc?) Let me know what you think. -- Ticket URL: <http://www.macruby.org/trac/ticket/215#comment:3> MacRuby <http://macruby.org/>
#215: OpenSSL's SSLSocket appears not to be initialised correctly -------------------------------+-------------------------------------------- Reporter: celtic@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: openssl -------------------------------+-------------------------------------------- Comment(by eloy.de.enige@…): Hi. First of all thanks for your time and effort! However, please also supply test coverage for your patch which demoes at least the problems you were having and have fixed. Have a look at: http://www.macruby.org/trac/browser/MacRuby/trunk/test- macruby/cases/objc_test.rb for pointers on how to write these tests. This is especially important because at least the initialize problem is more likely a bug in MacRuby. -- Ticket URL: <http://www.macruby.org/trac/ticket/215#comment:4> MacRuby <http://macruby.org/>
#215: OpenSSL's SSLSocket appears not to be initialised correctly -------------------------------+-------------------------------------------- Reporter: celtic@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: openssl -------------------------------+-------------------------------------------- Comment(by celtic@…): Thanks in kind. :-) This looks like a great project, would love to help it along as much as I can. I've uploaded a new diff with test coverage. It turns out that rb_io_wait_readable is incredibly hard to call from Ruby-world - depending on a certain situation with sockets which seems pretty difficult to re- create in a testing environment. Hence, I've added a CCompiler class, styled from the ObjectiveC helper class. I would've done the obvious thing and used fork in openssl_test and watch the subprocess die, but it seems the the subprocess of a fork always segfaults on exit. I'll add a new ticket for that momentarily. As for the initialize bug, I think this is something I'll definitely look into soon. -- Ticket URL: <http://www.macruby.org/trac/ticket/215#comment:5> MacRuby <http://macruby.org/>
#215: OpenSSL's SSLSocket appears not to be initialised correctly -------------------------------+-------------------------------------------- Reporter: celtic@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: openssl -------------------------------+-------------------------------------------- Comment(by eloy.de.enige@…): Awesome, thanks will have a look asap. -- Ticket URL: <http://www.macruby.org/trac/ticket/215#comment:6> MacRuby <http://macruby.org/>
#215: OpenSSL's SSLSocket appears not to be initialised correctly -------------------------------+-------------------------------------------- Reporter: celtic@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: openssl -------------------------------+-------------------------------------------- Comment(by eloy.de.enige@…): So I had some time to look at this patch, but unfortunately I haven't been able to get the tests to work yet :( Here's what's going on; I applied your patch and wanted to first see if the tests would fail in the way I'd expect them to fail. That means, it compiles the IOWaitReadable.c file, runs it and _then_ crashes. However, the fixture does not compile in my case. See: http://gist.github.com/54690. Also, could you add the code that's in the other fixture, IOWaitReadable.rb, inline in the test? Because if it crashes during the tests execution I'll consider it a bug :) So it doesn't need to be ran in a sandbox and it will also not mask these kind of problems I was having above. Then finally I still wonder about why the fix is to move the initialize code into Ruby instead of C… Laurent care to comment at this, and on the whole patch in general? -- Ticket URL: <http://www.macruby.org/trac/ticket/215#comment:7> MacRuby <http://macruby.org/>
#215: OpenSSL's SSLSocket appears not to be initialised correctly -------------------------------+-------------------------------------------- Reporter: celtic@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: openssl -------------------------------+-------------------------------------------- Comment(by celtic@…): Alright, here's a fix - I was testing the tests (!) from the cases/ directory, rather than from where runner.rb was located, hence the CCompiler couldn't find ruby.h where it was looking ... I've inlined IOWaitReadable like you mentioned, ... and, I'm going to go hunt down why the C initialize is never called in the first place now! :-) -- Ticket URL: <http://www.macruby.org/trac/ticket/215#comment:8> MacRuby <http://macruby.org/>
#215: OpenSSL's SSLSocket appears not to be initialised correctly -------------------------------+-------------------------------------------- Reporter: celtic@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: openssl -------------------------------+-------------------------------------------- Comment(by eloy.de.enige@…): Ah I see. Well actually the tests should run from anywhere IMO, so we shouldn't use relative paths. But I can probably look at that as well now that I understand what the problem was. Looking forward to the results of your research on why it's never called. Hint: try `git bisect' if you aren't already using that :) -- Ticket URL: <http://www.macruby.org/trac/ticket/215#comment:9> MacRuby <http://macruby.org/>
#215: OpenSSL's SSLSocket appears not to be initialised correctly -------------------------------+-------------------------------------------- Reporter: celtic@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: openssl -------------------------------+-------------------------------------------- Comment(by celtic@…): Now that we're not launching the test externally, we need to provide some data on STDIN so that io_wait_readable returns (in the case where it actually works) ...! -- Ticket URL: <http://www.macruby.org/trac/ticket/215#comment:10> MacRuby <http://macruby.org/>
#215: OpenSSL's SSLSocket appears not to be initialised correctly -------------------------------+-------------------------------------------- Reporter: celtic@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: openssl -------------------------------+-------------------------------------------- Comment(by celtic@…): #218 reports on what could be causing the initialize problem - the modules which call `super' (which should call the C `initialize') in SSLSocket are included after the C `initialize' is declared (there's no other way); including 'masking' functions from modules appears to erroneously render them completely inaccessible in MacRuby. -- Ticket URL: <http://www.macruby.org/trac/ticket/215#comment:11> MacRuby <http://macruby.org/>
#215: OpenSSL's SSLSocket appears not to be initialised correctly -------------------------------+-------------------------------------------- Reporter: celtic@… | Owner: lsansonetti@… Type: defect | Status: closed Priority: major | Milestone: MacRuby 0.5 Component: MacRuby | Resolution: fixed Keywords: openssl | -------------------------------+-------------------------------------------- Changes (by lsansonetti@…): * status: new => closed * resolution: => fixed * milestone: => MacRuby 0.5 Comment: Looks like there was some iterations on this bug. However the IO layer changed a lot in 0.5, and as of r2915 it seems that the SSLSocket class is being "initialized" correctly (it does not crash). {{{ $ macruby -r openssl -r net/http -r net/https -e "p OpenSSL::SSL::SSLSocket.new(nil) " core:in `initialize:': wrong argument type nil (expected File) (TypeError) from core:in `__new__:' from -e:1:in `<main>' }}} I was not able to find a different snippet by reading the attachments, so I'm closing the bug, if something doesn't work still please provide a proper bug reduction. -- Ticket URL: <http://www.macruby.org/trac/ticket/215#comment:12> MacRuby <http://macruby.org/>
participants (1)
-
MacRuby