New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Current dll linking has timeouts on Windows #48

Open
danielpclark opened this Issue Oct 18, 2018 · 10 comments

Comments

2 participants
@danielpclark
Owner

danielpclark commented Oct 18, 2018

The Windows test suite runs but many to most of the tests now time out in windows. Even though a Ruby dependency libgmp-10.dll is in the path the linker is having issues linking with it. I have put forth my best efforts to making Rutie work for Windows. If you have a better understanding of linkers and dependencies and would like to see full Windows support please help with this issue.

@danielpclark

This comment has been minimized.

Owner

danielpclark commented Oct 28, 2018

Okay. So using the Visual Studio debugger I'm finding that everything that's failing is failing the same way. It looks like the binding::class::const_get method in Rutie is trying to access invalid memory only on Windows. The debugger shows the following message.

Unhandled exception at 0x0000000068034E74
(x64-mscvrt-ruby250.dll) in rust_out.exe: 0xC0000005:
Access violation reading location 0xFFFFFFFFFFFFFFFF

And it's highlighting

pub fn const_get(klass: Value, name: &str) -> Value {
    unsafe { class::rb_const_get(klass, symbol::internal_id(name)) }
}

as the problem area.

Maybe something between 64bit/32bit isn't quite right on Windows. ¯\_(ツ)_/¯

@pravic

This comment has been minimized.

pravic commented Nov 1, 2018

Hi, just walked by.

By linking you mean something different, a Ruby-specific, right? It was also mentioned in the README.

@danielpclark

This comment has been minimized.

Owner

danielpclark commented Nov 1, 2018

Thanks @pravic , but the tests in Rutie are all run from the Rust side and not from Ruby. What I mean by linking is the Rust compiler rustc has the GMP library linking the dll during compilation and has occasional issues with this library. So this issue isn't Ruby-specific.

Copying libgmp-10.dll to one of gmp-10.dll or gmp.dll may solve the linking issue for this dll. But it doesn't solve the timeouts.

@danielpclark danielpclark added bug and removed hacktoberfest labels Nov 1, 2018

@pravic

This comment has been minimized.

pravic commented Nov 1, 2018

It's still not clear.

How to reproduce? Just a cargo test? Also is it the msvc toolchain or the gnu one?

Sorry for silly questions, as a Windows citizen I'd can look, but I need some walk through.

@danielpclark

This comment has been minimized.

Owner

danielpclark commented Nov 1, 2018

Yes. Either toolchain should produce the same result. The TravisCI suite and myself are using the msvc toolchain. cargo test should be all you need to reproduce.

Primarily it will say something like rust_out.exe has timed out. If a copy of the GMP dll hasn't been made as I indicated above you may get a few dialogs popping up about it. If you have Visual Studio and you're on Windows 10 the time out error will show something like a “Debug” button which is where I gathered the info above from. You can also look under TravisCI for the full trace output: https://travis-ci.org/danielpclark/rutie/jobs/448965441

@pravic

This comment has been minimized.

pravic commented Nov 5, 2018

Well..

First of all, Ruby is compiled by MinGW by default, so it's quite hard to debug. I've recompiled it with MSVC (win32\configure.bat --target=x64-mswin64 --disable-install-doc --disable-rubygems --without-ext=ripper).

Then I tried to debug and it has crashed inside _pioinfo(int fd) in win32.c, because __pioinfo was not initialized, because set_pioinfo_extra wasn't called.

However, after I added ruby_sysinit it still crashed in rb_ec_tag_jump because of null ec->tag. The exception raised after Class::new("SomeClass", None) with message "wrong argument type Integer (expected Class)". Apparently, it doesn't like to make a new class that inherits Integer (is rb_cObject an integer?).

pub fn init() {
    unsafe {
        let mut argc = 0;
        let mut argv = std::ptr::null_mut();
        vm::ruby_sysinit(&mut argc as *mut _, &mut argv as *mut _);
        vm::ruby_init();
    }
}
@danielpclark

This comment has been minimized.

Owner

danielpclark commented Nov 6, 2018

ec is the execution context for which the Ruby code is to execute in and perhaps one can't exist before vm::ruby_init()? nil from NilClass should be a valid parameter for an alternative execution context, but not null.

Each VALUE object in Ruby has an internal type associated with it. It sounds like the ValueType aka ruby_value_type ended up being 0x15 instead of 0x02 which would possibly explain the Integer message. Although I doubt that is useful to know.

My thoughts on how I'd possibly try to sort this out are of two mindsets. Since older versions of this project did work with older versions of Ruby and Rust then it may be good to work backwards to find what was the breaking change (this is the most tedious route IMO). The other is that since all the errors I've gotten seem to be related to only one method then I can try rewriting Ruby's internal id lookup in Rust and have Windows use that... in other words simply sidestep the issue. I'm not sure when I'd have time to take on this task but this is the strategy I've thought of.

@pravic

This comment has been minimized.

pravic commented Nov 6, 2018

Yes, I tested on the latest Ruby version. Is there any other known-good version instead?

@danielpclark

This comment has been minimized.

Owner

danielpclark commented Nov 6, 2018

Here's the .appveyor.yml file from RuRu https://github.com/d-unseductable/ruru/blob/master/.appveyor.yml . It worked with Ruby 2.4 with Rust's GNU toolchain for Rust 1.16. Rutie has since added features requiring later versions of Rust so rolling back Rust versions could be difficult.

@pravic

This comment has been minimized.

pravic commented Nov 6, 2018

No, it's not about Rust version. It's about compatibility with the MSVC runtime (CRT).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment