[#75687] [Ruby trunk Bug#12416] struct rb_id_table lacks mark function — shyouhei@...
Issue #12416 has been reported by Shyouhei Urabe.
3 messages
2016/05/23
[#75763] [Ruby trunk Feature#12435] Using connect_nonblock to open TCP connections in Net::HTTP#connect — mohamed.m.m.hafez@...
Issue #12435 has been reported by Mohamed Hafez.
3 messages
2016/05/28
[#75774] Errno::EAGAIN thrown by OpenSSL::SSL::SSLSocket#connect_nonblock — Mohamed Hafez <mohamed.m.m.hafez@...>
Hi all, every now and then in my production server, I'm
4 messages
2016/05/30
[#75775] Re: Errno::EAGAIN thrown by OpenSSL::SSL::SSLSocket#connect_nonblock
— Mohamed Hafez <mohamed.m.m.hafez@...>
2016/05/30
Or does MRI's OpenSSL::SSL::SSLSocket#connect_nonblock just return
[#75782] Important: Somewhat backwards-incompatible change (Fwd: [ruby-cvs:62388] duerst:r55225 (trunk): * string.c: Activate full Unicode case mapping for UTF-8) — Martin J. Dürst <duerst@...>
With the change below, I have activated full Unicode case mapping for
4 messages
2016/05/31
[ruby-core:75581] [Ruby trunk Feature#6647] Exceptions raised in threads should be logged
From:
headius@...
Date:
2016-05-17 20:27:44 UTC
List:
ruby-core #75581
Issue #6647 has been updated by Charles Nutter.
> Benoit, I advise you to compromise on the default value. Once this feature gets implemented, its default value could be flipped later I think. We technically can't do what is proposed here now, which is definitely worse than a wrong default. no?
I am confused what it is we "can't" do right now. Do you mean: there's no reporting currently and we're seeking to add it...off by default but at least better than we have now?
I guess it's a *little* better because you could turn it on to see what's happening to all those badly-behaved threads, but it seems like having it off by default means most people never see any benefit.
I would try to keep convincing you all, but it seems the majority do not want it on by default. I'll just reiterate that I believe most of the purpose of this PR is lost if threads continue to die silently by default.
What about having verbose mode set Thread.report_on_exception = true? At least then people could pass a command-line flag to look for exception-killing threads without using `-d` and logging *all* exceptions.
1. User runs app with threads...threads disappear without reporting.
2. User runs app with -v (or some other flag to enable thread exception logging) to see why threads are dying.
3. User fixes app to properly handle exceptions in those threads.
----------------------------------------
Feature #6647: Exceptions raised in threads should be logged
https://bugs.ruby-lang.org/issues/6647#change-58715
* Author: Charles Nutter
* Status: Assigned
* Priority: Normal
* Assignee: Yukihiro Matsumoto
----------------------------------------
Many applications and users I have dealt with have run into bugs due to Ruby's behavior of quietly swallowing exceptions raised in threads. I believe this is a bug, and threads should always at least log exceptions that bubble all the way out and terminate them.
The implementation should be simple, but I'm not yet familiar enough with the MRI codebase to provide a patch. The exception logging should be logged in the same way top-level exceptions get logged, but perhaps with information about the thread that was terminated because of the exception.
Here is a monkey patch that simulates what I'm hoping to achieve with this bug:
```ruby
class << Thread
alias old_new new
def new(*args, &block)
old_new(*args) do |*bargs|
begin
block.call(*bargs)
rescue Exception => e
raise if Thread.abort_on_exception || Thread.current.abort_on_exception
puts "Thread for block #{block.inspect} terminated with exception: #{e.message}"
puts e.backtrace.map {|line| " #{line}"}
end
end
end
end
Thread.new { 1 / 0 }.join
puts "After thread"
```
Output:
```
system ~/projects/jruby $ ruby thread_error.rb
Thread for block #<Proc:0x000000010d008a80@thread_error.rb:17> terminated with exception: divided by 0
thread_error.rb:17:in `/'
thread_error.rb:17
thread_error.rb:7:in `call'
thread_error.rb:7:in `new'
thread_error.rb:5:in `initialize'
thread_error.rb:5:in `old_new'
thread_error.rb:5:in `new'
thread_error.rb:17
After thread
```
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>