[#61822] Plan Developers Meeting Japan April 2014 — Zachary Scott <e@...>
I would like to request developers meeting around April 17 or 18 in this month.
14 messages
2014/04/03
[#61825] Re: Plan Developers Meeting Japan April 2014
— Urabe Shyouhei <shyouhei@...>
2014/04/03
It's good if we have a meeting then.
[#61826] Re: Plan Developers Meeting Japan April 2014
— Zachary Scott <e@...>
2014/04/03
Regarding openssl issues, I’ve discussed possible meeting time with Martin last month and he seemed positive.
[#61833] Re: Plan Developers Meeting Japan April 2014
— Martin Bo煬et <martin.bosslet@...>
2014/04/03
Hi,
[#61847] Re: Plan Developers Meeting Japan April 2014
— Eric Wong <normalperson@...>
2014/04/03
Martin Boテ殕et <martin.bosslet@gmail.com> wrote:
[#61849] Re: Plan Developers Meeting Japan April 2014
— Zachary Scott <e@...>
2014/04/04
I will post summary of meeting on Google docs after the meeting.
[#61852] Re: Plan Developers Meeting Japan April 2014
— Eric Wong <normalperson@...>
2014/04/04
Zachary Scott <e@zzak.io> wrote:
[#61860] Re: Plan Developers Meeting Japan April 2014
— Zachary Scott <e@...>
2014/04/04
I’m ok with redmine, thanks for bringing up your concern!
[#62076] Candidacy to 2.1 branch maintainer. — Tomoyuki Chikanaga <nagachika00@...>
Hello,
7 messages
2014/04/17
[#62078] Re: Candidacy to 2.1 branch maintainer.
— SHIBATA Hiroshi <shibata.hiroshi@...>
2014/04/17
> And does anyone have counter proposal for 2.1 maintenance?
[ruby-core:61926] [ruby-trunk - Bug #9719] [Open] longjmp causes uninitialized stack frame on threaded procs
From:
xangelux@...
Date:
2014-04-09 19:51:03 UTC
List:
ruby-core #61926
Issue #9719 has been reported by Brian Martinez. ---------------------------------------- Bug #9719: longjmp causes uninitialized stack frame on threaded procs https://bugs.ruby-lang.org/issues/9719 * Author: Brian Martinez * Status: Open * Priority: Normal * Assignee: * Category: * Target version: * ruby -v: 2.1.0, 2.1.1 * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN ---------------------------------------- I'm developing a script that uses tiny_tds and mechanize. There is an implementation of threads spawning connections to a database(tiny_tds) using transactions and rescuing deathlocks, to one site (using mechanize). There are 6 threads spawned and then joined. Everything goes well but in random times the script dies with the message: *** longjmp causes uninitialized stack frame ***: ruby terminated The backtrace is: ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7fc0fba07f47] /lib/x86_64-linux-gnu/libc.so.6(+0x10aebd)[0x7fc0fba07ebd] /lib/x86_64-linux-gnu/libc.so.6(__longjmp_chk+0x33)[0x7fc0fba07e23] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(+0x75f0b)[0x7fc0fbd32f0b] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(+0x76c44)[0x7fc0fbd33c44] /home/brian/.rvm/gems/ruby-2.1.1/extensions/x86_64-linux/2.1.0/tiny_tds-0.6.1/tiny_tds/tiny_tds.so(+0x4b8b)[0x7fc0f66abb8b] /home/brian/.rvm/gems/ruby-2.1.1/extensions/x86_64-linux/2.1.0/tiny_tds-0.6.1/tiny_tds/tiny_tds.so(+0x4da0)[0x7fc0f66abda0] /usr/lib/x86_64-linux-gnu/libsybdb.so.5(+0x185d0)[0x7fc0f64585d0] /usr/lib/x86_64-linux-gnu/libsybdb.so.5(+0x257d8)[0x7fc0f64657d8] /usr/lib/x86_64-linux-gnu/libsybdb.so.5(+0x25052)[0x7fc0f6465052] /usr/lib/x86_64-linux-gnu/libsybdb.so.5(+0x269ce)[0x7fc0f64669ce] /usr/lib/x86_64-linux-gnu/libsybdb.so.5(dbsqlok+0x92)[0x7fc0f6450032] /home/brian/.rvm/gems/ruby-2.1.1/extensions/x86_64-linux/2.1.0/tiny_tds-0.6.1/tiny_tds/tiny_tds.so(+0x2911)[0x7fc0f66a9911] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(+0x1bd21e)[0x7fc0fbe7a21e] /home/brian/.rvm/gems/ruby-2.1.1/extensions/x86_64-linux/2.1.0/tiny_tds-0.6.1/tiny_tds/tiny_tds.so(+0x3d3b)[0x7fc0f66aad3b] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(+0x19c59a)[0x7fc0fbe5959a] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(+0x1a06c9)[0x7fc0fbe5d6c9] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(+0x1a5287)[0x7fc0fbe62287] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(+0x1a705b)[0x7fc0fbe6405b] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(rb_yield+0xfb)[0x7fc0fbe68c1b] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(+0xc2622)[0x7fc0fbd7f622] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(+0x19c59a)[0x7fc0fbe5959a] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(+0x1a0c24)[0x7fc0fbe5dc24] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(+0x1a5287)[0x7fc0fbe62287] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(+0x1a705b)[0x7fc0fbe6405b] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(rb_yield+0xfb)[0x7fc0fbe68c1b] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(rb_ary_each+0x52)[0x7fc0fbceacf2] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(+0x19c59a)[0x7fc0fbe5959a] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(+0x1a0c24)[0x7fc0fbe5dc24] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(+0x1a5287)[0x7fc0fbe62287] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(+0x1a705b)[0x7fc0fbe6405b] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(+0x1a723e)[0x7fc0fbe6423e] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(+0x1a72ad)[0x7fc0fbe642ad] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(+0x1bb028)[0x7fc0fbe78028] /home/brian/.rvm/rubies/ruby-2.1.1/lib/libruby.so.2.1(+0x1bb36c)[0x7fc0fbe7836c] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7fc0fb6e7e9a] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fc0fb9f13fd] I assume this has to do with the manage of threads (because of the longjmp) I think the issue is the combination of tiny_tds and threading, every thread is trying to commit a transaction in the same database and the same tables, this is rescued and the transaction which fails rolls back and then retries. I don't know if this happends when the control changes from one thread to another causing some weird context failure when the longjmp takes place. -- https://bugs.ruby-lang.org/