Yesterday, I got ruby-openid to work with Ruby 1.9, rev 15006 http://lists.openidenabled.com/pipermail/dev/2008-January/001001.html As of a rev 15047, I am once again able to build ruby (thanks!), but now I am seeing a reproducible trap in OpenID. I'm also seeing other oddities with encodings that I will try to build a more focused test case for. An addr2line augmented output from the unit tests is attached. - SaRuby
on 14.01.2008 15:43
on 14.01.2008 16:11
Hi, At Mon, 14 Jan 2008 23:41:26 +0900, Sam Ruby wrote in [ruby-core:15069]: > [BUG] native_mutex_destroy return non-zero: 16 Errno 16 is EBUSY? > /home/rubys/svn/ruby/process.c:1314 > /home/rubys/svn/ruby/process.c:1411 > /home/rubys/svn/ruby/process.c:1732 > /home/rubys/svn/ruby/process.c:1790 Seems using spawn. Process.fork eliminates all other threads except for the thread called it, without any cleanup. Mutexes would be left locked. It's a tough problem to define.
on 14.01.2008 21:35
Nobuyoshi Nakada wrote: > Hi, > > At Mon, 14 Jan 2008 23:41:26 +0900, > Sam Ruby wrote in [ruby-core:15069]: >> [BUG] native_mutex_destroy return non-zero: 16 > > Errno 16 is EBUSY? I believe so, yes. >> /home/rubys/svn/ruby/process.c:1314 >> /home/rubys/svn/ruby/process.c:1411 >> /home/rubys/svn/ruby/process.c:1732 >> /home/rubys/svn/ruby/process.c:1790 > > Seems using spawn. Process.fork eliminates all other threads > except for the thread called it, without any cleanup. Mutexes > would be left locked. > It's a tough problem to define. Does it help to know that reverting the following change makes the problem go away? http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/trunk/thread.c?r1=15044&r2=15043&pathrev=15044 - Sam Ruby
on 15.01.2008 03:25
Sam Ruby wrote: > > I'm also seeing other > oddities with encodings that I will try to build a more focused test > case for. I'm giving up building a smaller test case for the moment. The symptoms are rather odd, and literally takes only ten seconds to recreate -- including the downloads. svn checkout -r 110 http://builder.rubyforge.org/svn/trunk/ builder wget http://intertwingly.net/stories/2008/01/04/builder5.diff cd builder patch -p 0 < ../builder5.diff export RUBYLIB=lib rake test_all # 101 tests, 173 assertions, 0 failures, 0 errors mv test/test_xchar.rb test/test_xchar.save sed -e 's/force_encoding.*/force_encoding(Encoding.find("BINARY"))/' < test/test_xchar.save > test/test_xchar.rb rake test_all # ArgumentError: unknown encoding name - BINARY rm test/test_markupbuilder.rb rm test/test_eventbuilder.rb rake test_all # 30 tests, 39 assertions, 0 failures, 0 errors What's going on here is that I have a patch that makes builder pass its unit test suite on Ruby 1.9, but if I change one line to find the encoding named 'BINARY' later on in the run, it fails, even though it was able to find this alias for the encoding earlier in the run. If I then remove some unrelated tests (both sets need to be removed, removing just one isn't sufficient), and the tests pass again. Also of note: while finding the 'BINARY' encoding fails, finding 'ASCII-8BIT' succeeds. This test passes on revision 15007 of ruby, but not on revision 15047. - Sam Ruby
on 15.01.2008 03:36
Hi, At Tue, 15 Jan 2008 05:35:00 +0900, Sam Ruby wrote in [ruby-core:15072]: > Does it help to know that reverting the following change makes the > problem go away? > > http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/trunk/thread.c?r1=15044&r2=15043&pathrev=15044 OK, it seems too strictly. Does this patch help? Index: thread.c =================================================================== --- thread.c (revision 15054) +++ thread.c (working copy) @@ -282,5 +282,4 @@ thread_cleanup_func(void *th_ptr) th->machine_register_stack_start = th->machine_register_stack_end = 0; #endif - native_mutex_destroy(&th->interrupt_lock); native_thread_destroy(th); } Index: thread_pthread.c =================================================================== --- thread_pthread.c (revision 15054) +++ thread_pthread.c (working copy) @@ -14,5 +14,4 @@ static void native_mutex_lock(pthread_mutex_t *lock); static void native_mutex_unlock(pthread_mutex_t *lock); -static void native_mutex_destroy(pthread_mutex_t *lock); static int native_mutex_trylock(pthread_mutex_t *lock); static void native_mutex_initialize(pthread_mutex_t *lock); @@ -157,4 +156,5 @@ static void native_thread_destroy(rb_thread_t *th) { + pthread_mutex_destroy(&th->interrupt_lock); pthread_cond_destroy(&th->native_thread_data.sleep_cond); } Index: thread_win32.c =================================================================== --- thread_win32.c (revision 15054) +++ thread_win32.c (working copy) @@ -419,4 +419,5 @@ native_thread_destroy(rb_thread_t *th) { HANDLE intr = th->native_thread_data.interrupt_event; + native_mutex_destroy(&th->interrupt_lock); thread_debug("close handle - intr: %p, thid: %p\n", intr, th->thread_id); th->native_thread_data.interrupt_event = 0;
on 15.01.2008 04:23
Nobuyoshi Nakada wrote: > > Does this patch help? Yes! :-) > Index: thread_pthread.c > native_thread_destroy(rb_thread_t *th) > HANDLE intr = th->native_thread_data.interrupt_event; > + native_mutex_destroy(&th->interrupt_lock); > thread_debug("close handle - intr: %p, thid: %p\n", intr, th->thread_id); > th->native_thread_data.interrupt_event = 0; - Sam Ruby
on 16.01.2008 08:16
Sam Ruby wrote: >> >> OK, it seems too strictly. >> >> Does this patch help? > > Yes! :-) Would it be possible for this patch to get committed? It would be nice to see ruby-openid passing its unit test suite again. http://intertwingly.net/projects/ruby19/logs/openid.html - Sam Ruby