WIP: Ruby on Rails 4.0, help with thread safe needed

2014-01-03 Thread Alexey Suslikov
Hi ports@.

Roman Kravchuk and me are working on Ruby on Rails 4.0 port (incl
Active Record and such).

Although we got it running and working (at first glance), there
is one thing which bothers us (hence the kinda preliminary mail).

Ruby thread safe library (which RoR 4.0 depends on) fails to pass
test suite: most of the time it segfaults at 50 of 68 tests (as
I said before, RoR 4.0 itself is working at first glance).

Same test suite works under Ubuntu Linux:

Finished tests in 475.533748s, 0.1430 tests/s, 5.0827 assertions/s.
68 tests, 2417 assertions, 0 failures, 0 errors, 0 skips

ruby -v: ruby 2.0.0p353 (2013-11-22 revision 43784) [x86_64-linux-gnu]

So at this point we'd love to receive some help from other people
on (possible) threading issues.

Attached are Ruby thread safe port and accompanying Ruby atomic.

With Ruby thread safe tests, the following will give verbose output:
cd `make show=WRKSRC`  rake20 --trace test

Tested here on -current amd64 (Ruby atomic tests also pass).

Cheers,
Alexey


ruby-thread_safe.tgz
Description: GNU Zip compressed data


ruby-atomic.tgz
Description: GNU Zip compressed data


Re: WIP: Ruby on Rails 4.0, help with thread safe needed

2014-01-03 Thread Jeremy Evans
On 01/03 03:08, Alexey Suslikov wrote:
 Hi ports@.
 
 Roman Kravchuk and me are working on Ruby on Rails 4.0 port (incl
 Active Record and such).
 
Offtopic, but:

We did have a previous rails port, which was removed, partly because it
was old and insecure, and partly because the benefit of the port does
not outweigh the cost.  Search the ports@ archives for details.

If you are planning on submitting the port for inclusion in the ports
system, you'll have to explain how the benefits outweight the costs.

 Although we got it running and working (at first glance), there
 is one thing which bothers us (hence the kinda preliminary mail).
 
 Ruby thread safe library (which RoR 4.0 depends on) fails to pass
 test suite: most of the time it segfaults at 50 of 68 tests (as
 I said before, RoR 4.0 itself is working at first glance).
 
 Same test suite works under Ubuntu Linux:
 
 Finished tests in 475.533748s, 0.1430 tests/s, 5.0827 assertions/s.
 68 tests, 2417 assertions, 0 failures, 0 errors, 0 skips
 
 ruby -v: ruby 2.0.0p353 (2013-11-22 revision 43784) [x86_64-linux-gnu]
 
 So at this point we'd love to receive some help from other people
 on (possible) threading issues.
 
 Attached are Ruby thread safe port and accompanying Ruby atomic.
 
 With Ruby thread safe tests, the following will give verbose output:
 cd `make show=WRKSRC`  rake20 --trace test
 
 Tested here on -current amd64 (Ruby atomic tests also pass).

I tested on a not-so-current -current on amd64 and everything passes:

Finished tests in 1466.086436s, 0.0464 tests/s, 1.6486 assertions/s.

68 tests, 2417 assertions, 0 failures, 0 errors, 0 skips

ruby -v: ruby 2.0.0p353 (2013-11-22 revision 43784) [x86_64-openbsd]
$ dmesg |head -n1
OpenBSD 5.4-current (GENERIC.MP) #195: Mon Dec  9 16:34:18 MST 2013


On i386, the first time I ran the tests, they didn't segfault, but
the tests don't complete:
...
TestCacheTorture#test_put_if_absent = 103.66 s = .
TestHash#test_concurrency = 
/usr/obj/ports/thread_safe-0.1.3-ruby20/thread_safe-0.1.3/test/test_hash.rb:11:in
 `[]=': can't add a new key into hash during iteration (RuntimeError)
from 
/usr/obj/ports/thread_safe-0.1.3-ruby20/thread_safe-0.1.3/test/test_hash.rb:11:in
 `block (4 levels) in test_concurrency'
from 
/usr/obj/ports/thread_safe-0.1.3-ruby20/thread_safe-0.1.3/test/test_hash.rb:10:in
 `times'
from 
/usr/obj/ports/thread_safe-0.1.3-ruby20/thread_safe-0.1.3/test/test_hash.rb:10:in
 `block (3 levels) in test_concurrency'
rake aborted!

I'm not sure why this wasn't just a failure and why it caused the test
suite to abort.  

The second time, I did get a segfault, on a test that passed on the
previous run:

TestCacheTorture#test_add_remove_to_zero = 
/usr/obj/ports/thread_safe-0.1.3-ruby20/thread_safe-0.1.3/lib/thread_safe/non_concurrent_cache_backend.rb:10:
 [BUG] Segmentation fault

GDB backtrace looks like:

(gdb) bt
#0  0x0e6cf68d in kill () at stdin:2
#1  0x0e73a416 in raise (s=6) at /usr/src/lib/libc/gen/raise.c:39
#2  0x0e73a33c in abort () at /usr/src/lib/libc/stdlib/abort.c:70
#3  0x0e2dc21d in rb_bug () from /usr/local/lib/libruby20.so.0.1
#4  0x0e39089a in sigsegv () from /usr/local/lib/libruby20.so.0.1
#5  signal handler called
#6  0x0e398509 in find_entry () from /usr/local/lib/libruby20.so.0.1
#7  0x0e398626 in st_lookup () from /usr/local/lib/libruby20.so.0.1
#8  0x0e2f8b8a in rb_hash_aref () from /usr/local/lib/libruby20.so.0.1
#9  0x0e3f4adf in vm_exec_core () from /usr/local/lib/libruby20.so.0.1
#10 0x0e3f8866 in vm_exec () from /usr/local/lib/libruby20.so.0.1

Is this the same segfault that you were receiving?

The i386 machine was running:

ruby 2.0.0p353 (2013-11-22 revision 43784) [i386-openbsd]
$ dmesg |head -n1
OpenBSD 5.4-current (GENERIC.MP) #152: Sat Nov 30 00:50:11 MST 2013

Not sure how much this information helps, though.

Thanks,
Jeremy