0bbc4ed broke install of ffi2-generators gem

[jc00ke]

$> git checkout 0bbc4ed
$> ./configure && rake build
...
Installed ffi2-generators (0.1.1)
Building native extensions. This could take a while...

And it does. I believe this change is why the Travis build errored out for Linux/gcc, but regardless, I can't even get rbx to build on 656d690 😦

[tak1n]

Can confirm this:

λ bennyklotz rubinius → λ git master* → ./configure --prefix=/home/benny/.rubies/rbx && rake
...
/home/benny/ruby_downloads/rubinius/staging/bin/rbx extconf.rb
/home/benny/ruby_downloads/rubinius/staging/bin/rbx /home/benny/ruby_downloads/rubinius/rakelib/preinstall_gems.rb
Pre-installing gems for 2.1.0...
Installed bundler (1.6.2)
Installed ffi2-generators (0.1.1)
Building native extensions.  This could take a while...

[tak1n]

Added p gem to the line after https://github.com/rubinius/rubinius/blob/master/rakelib/preinstall_gems.rb#L25

The output is:

...
Pre-installing gems for 2.1.0...
"bundler-1.6.2.gem"
Installed bundler (1.6.2)
"ffi2-generators-0.1.1.gem"
Installed ffi2-generators (0.1.1)
"json-1.8.1.gem"
Building native extensions.  This could take a while...

json native ext is building forever, not sure why, also I'm not very experienced with debugging C ext's
so thats the only info I can give.

Using the same configure command as above, so I'm using gcc for compiling.
Also tried clang, same behaviour.

[tak1n]

Also deleted json gem from gems_list.txt to see if it's a problem with this gem only.
When trying to build without json gem it's hanging on racc native ext, so I think it's a problem with c ext's in general.

/home/benny/ruby_downloads/rubinius/staging/bin/rbx /home/benny/ruby_downloads/rubinius/rakelib/preinstall_gems.rb
Pre-installing gems for 2.1.0...
"bundler-1.6.2.gem"
Installed bundler (1.6.2)
"ffi2-generators-0.1.1.gem"
Installed ffi2-generators (0.1.1)
"minitest-4.7.5.gem"
Installed minitest (4.7.5)
"racc-1.4.11.gem"
Building native extensions.  This could take a while...

[yorickpeterse]

This is unrelated to the specific Gem, the problem in particular occurs whenever a fork() is executed. I did some digging and it appears that Console::stop_threads is waiting for various threads to complete (https://github.com/rubinius/rubinius/blob/master/vm/console.cpp#L187). One of the threads is running the following (on Linux): https://github.com/rubinius/rubinius/blob/master/vm/builtin/fsevent.cpp#L122. The particular problem occurs because this read() call never appears to return.

You can "solve" the problem by mocking it using something along the lines of status = 0. This however will result in at least 1 CPU core being eaten alive as this method is called quite often.

I did some digging around but it's not entirely clear what's causing the read() to block. I messed around with alternatives to pthread_join (e.g. pthread_cancel) but those don't appear to do anything but segfault Rbx in the worst cases.

You can mess around with this by running rake install in one terminal, followed by sudo gdb attach $(pidof rbx) in another terminal. Then run thread apply all bt to see the thread backtraces. When terminating, make sure you use kill (or use kill -9 $(pidof rbx) afterwards) as otherwise the process will keep running. Due to it being frozen it no longer responds properly to terminal signals such as ^C.

[tak1n]

Thanks for this detailed description, I'll try to mess around with gdb etc..
Even if I'm not experienced in C++ / C, maybe I'll find something :)

[tak1n]

Should be fixed by @brixen