Project

General

Profile

Bug #8996

pthread_mutex_lock EINVAL

Added by stevegoobermanhill (stephen gooberman-hill) over 3 years ago. Updated 3 months ago.

Status:
Closed
Priority:
Normal
Target version:
-
ruby -v:
2.2.2p95 2.3.1p112
[ruby-core:57725]

Description

ruby crashes leaving a stacktrace. . Cause is pthread_mutex_lock EINVAL

Based on the ruby source line where the problem happens (line 121 below)

119 def stop
120 if @tcpServerThread
121 @tcpServerThread.raise StandardError,"stop"
122 end
123 end

I suspect that the problem is there is a kind of race condition where @tcpServerThread has actually been destroyed (or is in the process of being destroyed) between lines 120 and 121. I am guessing that this results in thread_pthread.c (line 212 where the error occurs) checking that the pthread_mutex is either available or in EBUSY state, and throwing an error when it is not.

I'm not sure how one would solve it though...

Kind regards

Steve

top of the control frame information
-- Control frame information -----------------------------------------------
c:0032 p:---- s:0133 e:000132 CFUNC :raise
c:0031 p:0025 s:0128 e:000127 METHOD /home/steve/git/trident/lib/rmodbus/genserver.rb:121
c:0030 p:0008 s:0125 e:000124 METHOD /home/steve/git/trident/lib/db_client/data_cache_server.rb:344
c:0029 p:0014 s:0122 e:000121 METHOD /home/steve/git/trident/lib/rmodbus/genserver.rb:138
c:0028 p:0008 s:0119 e:000118 METHOD /home/steve/git/trident/lib/db_client/data_cache_server.rb:350
c:0027 p:0007 s:0116 e:000115 METHOD /home/steve/git/trident/lib/rmodbus/genserver.rb:142
c:0026 p:0030 s:0113 e:000112 METHOD /home/steve/git/trident/test/interface/test_stats_reporter.rb:114
c:0025 p:0009 s:0110 e:000109 LAMBDA /home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/gems/2.0.0/gems/test-unit-2.5.5/lib/test/unit/fixture.rb:202 [FINISH]

-- C level backtrace information -------------------------------------------
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(+0x1b04d8) [0x7f7d677324d8] vm_dump.c:647
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(+0x6a317) [0x7f7d675ec317] error.c:283
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(rb_bug+0xb3) [0x7f7d675ed063] error.c:302
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(rb_bug_errno+0x3a) [0x7f7d675ed0aa] error.c:320
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(+0x1bac7a) [0x7f7d6773cc7a] thread_pthread.c:212
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(+0x19a7cf) [0x7f7d6771c7cf] vm_insnhelper.c:1469
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(+0x19f29a) [0x7f7d6772129a] insns.def:1017
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(+0x1a375a) [0x7f7d6772575a] vm.c:1201
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(+0x1a475e) [0x7f7d6772675e] vm.c:696
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(+0x1a479a) [0x7f7d6772679a] vm.c:715
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(+0x7939d) [0x7f7d675fb39d] proc.c:578
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(+0x19a7cf) [0x7f7d6771c7cf] vm_insnhelper.c:1469
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(+0x19f29a) [0x7f7d6772129a] insns.def:1017
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(+0x1a375a) [0x7f7d6772575a] vm.c:1201
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(rb_yield+0x190) [0x7f7d6772c4a0] vm.c:648
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(rb_ary_each+0x52) [0x7f7d675b2382] array.c:1678
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(+0x19a7cf) [0x7f7d6771c7cf] vm_insnhelper.c:1469
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(+0x19f22b) [0x7f7d6772122b] insns.def:1002
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(+0x1a375a) [0x7f7d6772575a] vm.c:1201
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(+0x1a475e) [0x7f7d6772675e] vm.c:696
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(+0x1a479a) [0x7f7d6772679a] vm.c:715
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(rb_proc_call+0x42) [0x7f7d675fbea2] proc.c:603
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(rb_exec_end_proc+0x1f1) [0x7f7d675f5be1] eval_jump.c:129
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(+0x73c9a) [0x7f7d675f5c9a] eval.c:118
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(ruby_cleanup+0x132) [0x7f7d675f5e12] eval.c:176
/home/steve/.rvm/rubies/ruby-2.0.0-p195/lib/libruby.so.2.0(ruby_run_node+0x23) [0x7f7d675f60f3] eval.c:307
/home/steve/.rvm/rubies/ruby-2.0.0-p195/bin/ruby() [0x40089b] main.c:36
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f7d671dbea5]

Associated revisions

Revision 57595
Added by ko1 (Koichi Sasada) 4 months ago

check thread deadness correctly.

Revision 57906
Added by naruse (Yui NARUSE) 3 months ago

merge revision(s) 57595: [Backport #8996]

check thread deadness correctly.

Revision 58027
Added by nagachika (Tomoyuki Chikanaga) 3 months ago

merge revision(s) 57595: [Backport #8996]

check thread deadness correctly.

Revision 58108
Added by usa (Usaku NAKAMURA) 3 months ago

merge revision(s) 57595: [Backport #8996]

check thread deadness correctly.

History

#1 [ruby-core:71433] Updated by sylvain.joyeux (Sylvain Joyeux) over 1 year ago

  • Backport deleted (1.9.3: UNKNOWN, 2.0.0: UNKNOWN)
  • ruby -v changed from ruby 2.0.0p195 (2013-05-14 revision 40734) [x86_64-linux] to ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux]

Got the same issue in the same conditions with
- ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux]
- ruby 2.1.6p336 (2015-04-13 revision 50298) [x86_64-linux]

The OP diagnosis seem to be the right one, the following very simple script allows to reproduce in a few seconds on 2.1.6

while true
    t = Thread.new { }
    t.raise Interrupt
end

(I don't have a 2.2 install handy, can't run it on 2.2 but I guess it would work there as well)

#2 [ruby-core:77315] Updated by sylvain.joyeux (Sylvain Joyeux) 9 months ago

  • ruby -v changed from ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux] to 2.2.2p95 2.3.1p112

still happening on 2.3.1

#3 [ruby-core:77319] Updated by noahgibbs (Noah Gibbs) 9 months ago

Also occurs on latest head of master (Git commit c9dd5918f40dc6df3a237f634b9689bfbb591662, git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@56188 b2dd03c8-39d4-4d8f-98ff-823fe69b080e).

#4 [ruby-core:77555] Updated by shyouhei (Shyouhei Urabe) 9 months ago

  • Assignee set to ko1 (Koichi Sasada)
  • Status changed from Open to Assigned

#5 [ruby-core:79493] Updated by ko1 (Koichi Sasada) 4 months ago

  • Status changed from Assigned to Closed

r57595 fixes this problem. Sorry for late response and thank you for your great simple reproducing code!

#6 [ruby-core:79495] Updated by nagachika (Tomoyuki Chikanaga) 4 months ago

  • Backport set to 2.2: REQUIRED, 2.3: REQUIRED, 2.4: REQUIRED

I filled Backport field according to the reported version.

#7 [ruby-core:80053] Updated by naruse (Yui NARUSE) 3 months ago

  • Backport changed from 2.2: REQUIRED, 2.3: REQUIRED, 2.4: REQUIRED to 2.2: REQUIRED, 2.3: REQUIRED, 2.4: DONE

ruby_2_4 r57906 merged revision(s) 57595.

#8 [ruby-core:80237] Updated by nagachika (Tomoyuki Chikanaga) 3 months ago

  • Backport changed from 2.2: REQUIRED, 2.3: REQUIRED, 2.4: DONE to 2.2: REQUIRED, 2.3: DONE, 2.4: DONE

ruby_2_3 r58027 merged revision(s) 57595.

#9 [ruby-core:80339] Updated by usa (Usaku NAKAMURA) 3 months ago

  • Backport changed from 2.2: REQUIRED, 2.3: DONE, 2.4: DONE to 2.2: DONE, 2.3: DONE, 2.4: DONE

ruby_2_2 r58108 merged revision(s) 57595.

Also available in: Atom PDF