1.3.0 breaks Ruby 1.8 compatibility with Timeout call

[david-mccullars]

With the addition of "Timeout.timeout(@start_timeout, Stomp::Error::StartTimeoutException.new(@start_timeout))" in lib/stomp/client.rb, Ruby 1.8 support is lost. The error received is "class or module required for rescue clause (TypeError)".

I did not see anywhere in the changelog where Ruby 1.8 support has officially been discontinued. If that was indeed intentional it would be really nice to add a note to the changelog so others won't fall into the same trap.

[gmallard]

On 10/16/2013 08:49 AM, David McCullars wrote:

With the addition of "Timeout.timeout(@start_timeout,
Stomp::Error::StartTimeoutException.new(@start_timeout))" in
lib/stomp/client.rb, Ruby 1.8 support is lost. The error received is
"class or module required for rescue clause (TypeError)".

I did not see anywhere in the changelog where Ruby 1.8 support has
officially been discontinued. If that was indeed intentional it would
be really nice to add a note to the changelog so others won't fall
into the same trap.

—
Reply to this email directly or view it on GitHub
#87.

There is no intention to drop 1.8.x support at this time.

Can you add some information about your exact Ruby version (output of
ruby -v)? And possibly supply a brief test that shows the problem? I
can not recreate that here, with four different 1.8.x versions.

Thanks, Guy

[david-mccullars]

We are using ree 1.8.7:

ruby 1.8.7 (2012-02-08 MBARI 8/0x6770 on patchlevel 358) [x86_64-linux], MBARI 0x6770, Ruby Enterprise Edition 2012.02

To reproduce I can do:

[~] ➔ ruby -rtimeout -e "Timeout.timeout(1, StandardError.new) { sleep 10 }"
/usr/local/rvm/rubies/ree-1.8.7-2012.02/lib/ruby/1.8/timeout.rb:69:in `timeout': class or module required for rescue clause (TypeError)
from -e:1

However, that same line of code against 1.9.3p194 works:

[~] ➔ ruby -rtimeout -e "Timeout.timeout(1, StandardError.new) { sleep 10 }"
-e:1:in sleep': execution expired (StandardError) from -e:1:inblock in

'
from /usr/local/rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/timeout.rb:68:in timeout' from -e:1:in'

[david-mccullars]

I should also point out this works in REE 1.8.7:

[~] ➔ ruby -rtimeout -e "Timeout.timeout(1, StandardError) { sleep 10 }"
/usr/local/rvm/rubies/ree-1.8.7-2012.02/lib/ruby/1.8/timeout.rb:64: execution expired (StandardError)
from -e:1

[david-mccullars]

Here is another way of reproducing:

in ree 1.8.7

[~] ➔ ruby -e "p RUBY_VERSION; e = StandardError.new; begin; raise e; rescue StandardError; p :CAUGHT; end"
"1.8.7"
:CAUGHT

[~] ➔ ruby -e "p RUBY_VERSION; e = StandardError.new; begin; raise e; rescue e; p :CAUGHT; end"
"1.8.7"
-e:1: class or module required for rescue clause (TypeError)

in 1.9.3

[~] ➔ ruby -e "p RUBY_VERSION; e = StandardError.new; begin; raise e; rescue StandardError; p :CAUGHT; end"
"1.9.3"
:CAUGHT

[~] ➔ ruby -e "p RUBY_VERSION; e = StandardError.new; begin; raise e; rescue e; p :CAUGHT; end"
"1.9.3"
:CAUGHT

[gmallard]

REE specific.

From an ancient CentOS system, standard Ruby install:

ruby -v*
ruby 1.8.5 (2006-08-25) [x86_64-linux]
**
ruby -rtimeout -e "Timeout.timeout(1, StandardError.new) { sleep 10 }"
/usr/lib/ruby/1.8/timeout.rb:54: execution expired (StandardError)
* from /usr/lib/ruby/1.8/timeout.rb:56:in `timeout'*
* from -e:1*
*
Are you willing to experiment?

Meanwhile, I will try to get REE installed somewhere, and experiment
with that.

[gmallard]

Bizarre.

Well, after investigation, not REE specific. Even with a REE install
all the gem unit tests pass! I do not understand that yet, because ....

Your example (which is totally not related to the gem) of:

ruby -rtimeout -e "Timeout.timeout(1, StandardError.new) { sleep 10 }"

is an entirely different story.

For that example, I see:

• Total failure under any 1.8.x system
• Total success under any 1.9.x system
• Total failure under any 2.0.0 system
• Total failure under any 2.1.0dev bleeding edge system

Issue status: thinking.

For the record my (Ubuntu) systems, built from Ruby repo, are:

1. 185_231 (2008-06-20 patchlevel 231)
2. 186_383 (2009-08-04 patchlevel 383)
3. 187_000 1.8.7 (2008-04-15 patchlevel 0)
4. 187_299 (2010-06-23 patchlevel 299)
5. 191_378 1.9.1p378 (2010-01-10)
6. 192_188 1.9.2p188 (2011-03-28 revision 31204)
7. 193_134 1.9.3p134 (2012-02-19 revision 34690)
8. ruby 1.9.2p290 (2011-07-04 revision 32477)
9. ruby 1.9.1p431 (2011-08-25 revision 26781) LOCALMODS
   a) ruby 1.9.3p358 (2012-12-22 revision 38541)
   b) ruby 2.0.0p0 (2013-02-24 revision 39473)
   c) ruby 2.1.0dev (2013-03-23 trunk 39878)
   d) ruby 2.1.0dev (2013-05-05 trunk 40584)
   e) ruby 2.0.0p195 (2013-05-14 revision 40731)
   f) ruby 2.0.0p247 (2013-06-27 revision 41672)

Ref:

https://gist.github.com/gmallard/7034128

On 10/17/2013 10:25 AM, Guy M. Allard wrote:

REE specific.

From an ancient CentOS system, standard Ruby install:

ruby -v*
ruby 1.8.5 (2006-08-25) [x86_64-linux]
**
ruby -rtimeout -e "Timeout.timeout(1, StandardError.new) { sleep 10 }"
/usr/lib/ruby/1.8/timeout.rb:54: execution expired (StandardError)
* from /usr/lib/ruby/1.8/timeout.rb:56:in `timeout'*
* from -e:1*
*
Are you willing to experiment?

Meanwhile, I will try to get REE installed somewhere, and experiment
with that.

[david-mccullars]

I certainly appreciate your thoroughness in looking at this -- thanks!

The reason I posted that piece of seemingly unrelated code was line 87 of lib/stomp/client.rb. From 1.2.16 to 1.3, the line "Timeout.timeout(@start_timeout, Stomp::Error::StartTimeoutException.new(@start_timeout))" was added, and that uses the Timeout.timeout(n, some_exception_instance) syntax as opposed to Timeout.timeout(n, some_exception_class). I thought by pointing out the difference in those two syntaxes in REE 1.8 (at least for me) it might expedite your troubleshooting.

[gmallard]

There is a fix for this on my personal github clone and a pull request
created for comments.

You could clone my personal repo:

https://github.com/gmallard/stomp.git

and build a gem from the 'dev' branch if you want to test.

[gmallard]

Status: Closed
Ref: bfa882a
Gem Version: 1.3.2

If the issue persists please reopen this issue or create a new issue.