Project

General

Profile

Bug #7648

GServer does not close cleanly from signal interrupt context

Added by jleo3 (Joe Leo) about 4 years ago. Updated over 3 years ago.

Status:
Rejected
Priority:
Normal
Target version:
ruby -v:
ruby 2.0.0dev (2013-01-02 trunk 38676) [i686-linux]
Backport:
[ruby-core:51226]

Description

SUMMARY:
When a signal interrupt is trapped, we can no longer call #close on GServer without it throwing a ThreadError.

STEPS TO REPEAT:
1) Run the following code:

require 'gserver'

server = GServer.new 8080
server.start
trap("SIGINT") { server.stop }
gets # or any command that keeps the process running

2) Hit CTRL+C or whichever command will send the interrupt signal to this program.

WHAT I EXPECTED: In version 1.9.3, CTRL+C sends an interrupt signal and the program exits cleanly.

WHAT HAPPENED: When running the version from trunk the following stack trace is thrown.

C/home/joe/.rvm/rubies/ruby-head/lib/ruby/2.0.0/gserver.rb:116:in synchronize': can't be called from trap context (ThreadError)
from /home/joe/.rvm/rubies/ruby-head/lib/ruby/2.0.0/gserver.rb:116:in
stop'
from gserver_bug.rb:5:in block in <main>'
from gserver_bug.rb:6:in
call'
from gserver_bug.rb:6:in gets'
from gserver_bug.rb:6:in
gets'
from gserver_bug.rb:6:in `'

POSSIBLY RELEVANT: https://bugs.ruby-lang.org/issues/6416

NOTE: This was tried with AND without RVM with the same results.

History

#1 [ruby-core:51406] Updated by jleo3 (Joe Leo) about 4 years ago

Confirming that this is still an issue on RC1:

ruby -v
ruby 2.0.0dev (2013-01-07 trunk 38733) [i686-linux]

/home/joe/lib/lib/ruby/2.0.0/gserver.rb:116:in synchronize': can't be called from trap context (ThreadError)
from /home/joe/lib/lib/ruby/2.0.0/gserver.rb:116:in
stop'
from /home/joe/dev/bane/lib/bane/launcher.rb:19:in block in stop'
from /home/joe/dev/bane/lib/bane/launcher.rb:19:in
each'
from /home/joe/dev/bane/lib/bane/launcher.rb:19:in stop'
from ./bin/bane:22:in
block in '
from /home/joe/lib/lib/ruby/2.0.0/gserver.rb:140:in call'
from /home/joe/lib/lib/ruby/2.0.0/gserver.rb:140:in
join'
from /home/joe/lib/lib/ruby/2.0.0/gserver.rb:140:in join'
from /home/joe/dev/bane/lib/bane/launcher.rb:15:in
block in join'
from /home/joe/dev/bane/lib/bane/launcher.rb:15:in each'
from /home/joe/dev/bane/lib/bane/launcher.rb:15:in
join'
from ./bin/bane:23:in `'

#2 [ruby-core:51641] Updated by ko1 (Koichi Sasada) about 4 years ago

  • Category set to lib
  • Target version set to 2.0.0

Who can check it?

#3 [ruby-core:52318] Updated by ko1 (Koichi Sasada) about 4 years ago

  • Assignee set to mame (Yusuke Endoh)

No response here.

#4 [ruby-core:52345] Updated by mame (Yusuke Endoh) about 4 years ago

  • Target version changed from 2.0.0 to next minor

#5 [ruby-core:55213] Updated by mame (Yusuke Endoh) almost 4 years ago

  • Status changed from Open to Assigned
  • Assignee changed from mame (Yusuke Endoh) to kosaki (Motohiro KOSAKI)

kosaki-san, what do you think?

--
Yusuke Endoh mame@tsg.ne.jp

#6 [ruby-core:56889] Updated by kosaki (Motohiro KOSAKI) over 3 years ago

  • Status changed from Assigned to Rejected

Holding mutex in trap is deadlockable. It is what ruby complained. The best workaround is to make new thread in trap handler and stop gserver asynchnorously, I think.

Also available in: Atom PDF