Project

General

Profile

Actions

Bug #9719

closed

longjmp causes uninitialized stack frame on threaded procs

Added by angelux (Brian Martinez) about 10 years ago. Updated over 4 years ago.

Status:
Closed
Assignee:
-
Target version:
-
ruby -v:
2.1.0, 2.1.1
[ruby-core:61926]

Description

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.

Actions #1

Updated by jeremyevans0 (Jeremy Evans) over 4 years ago

  • Status changed from Open to Closed
Actions

Also available in: Atom PDF

Like0
Like0