Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Trunk #1

Closed
wants to merge 1 commit into
from

Conversation

3 participants

alexkv commented Nov 11, 2010

Added tcp connection closing.
In case of a greate number of requests no close connection led to a bug.

modified: lib/xmlrpc/client.rb
Added tcp connection closing.
In case of a greate number of requests no close connection led to a bug.
Owner

shyouhei commented Nov 11, 2010

Hi. Is there any code to reproduce that bug? I want one (if any) because I just want to write a test case on it.

alexkv commented Nov 12, 2010

Hi. You can try this one.

Dummy server:


#!/usr/bin/ruby
require "xmlrpc/server"

s = XMLRPC::Server.new(8080) 
s.add_handler("dummy") do |a|
    'Yeah'
end
s.serve

Client:


#!/usr/bin/ruby

require 'xmlrpc/client'
1000.times{
    result = XMLRPC::Client.new2('http://localhost:8080/').call( 'dummy', ['Are you here?'])
    p result
}
Owner

shyouhei commented Nov 30, 2010

Hi, we are discussing this. Please stay tuned…

Member

nahi commented Jun 28, 2011

Sorry for late reply.

Axy, you can use call_async instead of call for such case (non Keep-Alive TCP connection which is closed per connection.)
Yeah, I think that method name is awfully confusing but we don't want to touch xmlrpc lib as far as possible.

alexkv commented Jun 28, 2011

Ok, tnx for the info.

On Tue, Jun 28, 2011 at 1:29 PM, nahi <
reply@reply.github.com>wrote:

Sorry for late reply.

Axy, you can use call_async instead of call for such case (non Keep-Alive
TCP connection which is closed per connection.)
Yeah, I think that method name is awfully confusing but we don't want to
touch xmlrpc lib as far as possible.

Reply to this email directly or view it on GitHub:
#1 (comment)

Best regards,

Aleksei Kvitinskii

@shyouhei shyouhei closed this Jun 29, 2011

andrewmains12 referenced this pull request in andrewmains12/ruby Nov 13, 2012

Merge pull request #1 from maxdjohnson/cs194_master
Basic naive, single-threaded queue implementation. Slow.

funny-falcon referenced this pull request in funny-falcon/ruby Aug 7, 2015

Merge pull request #1 from funny-falcon/mtbl
id_table.c: simple hash with quadratic probing

hsbt pushed a commit that referenced this pull request Feb 25, 2016

Reduce system calls by activating the `did_you_mean` gem.
Activating the gem puts the gem on the load path, where simply requiring
the file will search every gem that's installed until it can find a gem
that contains the `did_you_mean` file.

Calling RubyGems' `require` will search each installed gem until it can
find one that contains the file it should require.  This means that the
more gems you have installed, the longer it can take to require that
gem.

To see this in action, lets compare the number of `stat` calls for a
"bare require" vs the number of `stat` calls for a require that follows
a gem activation by using these two programs:

```
[aaron@TC rubygems (master)]$ cat req_dym.rb
begin
  require 'did_you_mean'
rescue LoadError
end
[aaron@TC rubygems (master)]$ cat gem_dym.rb
begin
  gem 'did_you_mean'
  require 'did_you_mean'
rescue Gem::LoadError, LoadError
end
```

The first program just requires the `did_you_mean` gem, where the second
one activates the gem, then requires it.  We can count the number of
`stat` calls using `dtrace`:

```
[aaron@TC rubygems (master)]$ ruby -v
ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin15]
[aaron@TC rubygems (master)]$ sudo dtrace -q -n 'syscall::stat*:entry { printf("%s\n", copyinstr(arg0)); }' -c`rbenv which ruby`" --disable-did_you_mean req_dym.rb" | wc -l

dtrace: error on enabled probe ID 3 (ID 826: syscall::stat64:entry): invalid user access in action #1 at DIF offset 24
dtrace: error on enabled probe ID 3 (ID 826: syscall::stat64:entry): invalid user access in action #1 at DIF offset 24
dtrace: error on enabled probe ID 3 (ID 826: syscall::stat64:entry): invalid user access in action #1 at DIF offset 24
dtrace: error on enabled probe ID 3 (ID 826: syscall::stat64:entry): invalid user access in action #1 at DIF offset 24
     283
[aaron@TC rubygems (master)]$ sudo dtrace -q -n 'syscall::stat*:entry { printf("%s\n", copyinstr(arg0)); }' -c`rbenv which ruby`" --disable-did_you_mean gem_dym.rb" | wc -l

dtrace: error on enabled probe ID 3 (ID 826: syscall::stat64:entry): invalid user access in action #1 at DIF offset 24
dtrace: error on enabled probe ID 3 (ID 826: syscall::stat64:entry): invalid user access in action #1 at DIF offset 24
dtrace: error on enabled probe ID 3 (ID 826: syscall::stat64:entry): invalid user access in action #1 at DIF offset 24
dtrace: error on enabled probe ID 3 (ID 826: syscall::stat64:entry): invalid user access in action #1 at DIF offset 24
      13
```

The "bare require" version does over 10x the number of stat calls
compared to the "gem, then require" version.  Of course the number for
the first one depends on the number of gems you have installed that sort
before the `did_you_mean` gem.

Lets also look at trunk Ruby:

```
[aaron@TC rubygems (master)]$ ruby -v
ruby 2.4.0dev (2016-02-25 trunk 53940) [x86_64-darwin15]
[aaron@TC rubygems (master)]$ sudo dtrace -q -n 'syscall::stat*:entry { printf("%s\n", copyinstr(arg0)); }' -c`rbenv which ruby`" --disable-did_you_mean req_dym.rb" | wc -l

dtrace: error on enabled probe ID 3 (ID 826: syscall::stat64:entry): invalid user access in action #1 at DIF offset 24
dtrace: error on enabled probe ID 3 (ID 826: syscall::stat64:entry): invalid user access in action #1 at DIF offset 24
dtrace: error on enabled probe ID 3 (ID 826: syscall::stat64:entry): invalid user access in action #1 at DIF offset 24
dtrace: error on enabled probe ID 3 (ID 826: syscall::stat64:entry): invalid user access in action #1 at DIF offset 24
    2325
[aaron@TC rubygems (master)]$ sudo dtrace -q -n 'syscall::stat*:entry { printf("%s\n", copyinstr(arg0)); }' -c`rbenv which ruby`" --disable-did_you_mean gem_dym.rb" | wc -l

dtrace: error on enabled probe ID 3 (ID 826: syscall::stat64:entry): invalid user access in action #1 at DIF offset 24
dtrace: error on enabled probe ID 3 (ID 826: syscall::stat64:entry): invalid user access in action #1 at DIF offset 24
dtrace: error on enabled probe ID 3 (ID 826: syscall::stat64:entry): invalid user access in action #1 at DIF offset 24
dtrace: error on enabled probe ID 3 (ID 826: syscall::stat64:entry): invalid user access in action #1 at DIF offset 24
     685
```

This change will reduce the number of `stat` calls on trunk Ruby too,
but since this installation doesn't have the `did_you_mean` gem,
RubyGems is still reading every gem spec file so that it can raise a
`Gem::LoadError` exception with a nice error message.  If we can modify
RubyGems a little, it may be possible to drop the number of stat calls
even on a Ruby installation that doesn't have the `did_you_mean` gem.

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@53941 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

spinute pushed a commit to spinute/ruby that referenced this pull request Sep 5, 2016

Merge pull request #1 from ruby/trunk
Update from original

hsbt pushed a commit that referenced this pull request Jan 30, 2017

#include <stdbool.h>
17+ years passed since standardized in ISO, 8 years since we added
AC_HEADER_STDBOOL to configure.in.  I'm quite confident that it's
already safe to use <stdbool.h>.

I understand that when we introduced AC_HEADER_STDBOOL, <stdbool.h>
was remain not included because C standard and SVR4 curses conflicted
miserably back then (#1).  Though I believe such situation has been
fixed already(#2), I'm afraid of your operating system might ship a
proprietary curses that still conflicts with the standard. So to avoid
potential problem, we limit the inclusion to our internal use only.

#1 : 1997 version of SUSv2 said bool is "defined though typedef" in
     <curses.h>, while C99 said bool is a macro, plus in C++ bool is a
     keyword.  AFASIK the curses library has never been a part of
     POSIX.

#2 : In reality ncurses and NetBSD curses both just follow C99 to
     include <stdbool.h> from <curses.h>.  I think C99 is now widely
     adopted.

----

	* internal.h: #include <stdbool.h> if present.  That is
	  believed to be the case for 99.9% systems that lives today.
	  Non-C99, non-C++ situations are intentionally left
	  undefined, advised by Motohiro Kosaki.  If you have such
	  compiler, please fill the definition appropriately.


git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@57460 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

trofi added a commit to trofi/ruby that referenced this pull request May 20, 2017

ia64: fix crash on register stack mark/sweep pass
The crash in ./miniruby looks like that:

  Program received signal SIGSEGV, Segmentation fault.
  mark_locations_array (objspace=0x6000000000045db0, x=0x0, n=864692227966763116) at gc.c:3297
  3297            v = *x;
  (gdb) bt
  #0  mark_locations_array (objspace=0x6000000000045db0, x=0x0, n=864692227966763116) at gc.c:3297
  #1  0x400000000014a040 in gc_mark_locations (objspace=0x6000000000045db0, start=0x0, end=0x6000080000000368) at gc.c:3310
  #2  0x400000000014b3a0 in mark_current_machine_context (objspace=0x6000000000045db0, th=0x60000000000455b0) at gc.c:3500
  #3  0x400000000014dfe0 in gc_mark_roots (objspace=0x6000000000045db0, full_mark=0, categoryp=0x0) at gc.c:4105
  #4  0x400000000014e6b0 in gc_marks_body (objspace=0x6000000000045db0, full_mark=0) at gc.c:4164
  #5  0x400000000014f260 in gc_marks (objspace=0x6000000000045db0, full_mark=0) at gc.c:4526
  #6  0x40000000001525c0 in garbage_collect_body (objspace=0x6000000000045db0, full_mark=0, immediate_sweep=0, reason=256) at gc.c:5024
  #7  0x400000000013c010 in heap_prepare_freepage (objspace=0x6000000000045db0, heap=0x6000000000045dc0) at gc.c:1219
  #8  0x400000000013c140 in heap_get_freeobj_from_next_freepage (objspace=0x6000000000045db0, heap=0x6000000000045dc0) at gc.c:1237
  #9  0x400000000013c360 in heap_get_freeobj (objspace=0x6000000000045db0, heap=0x6000000000045dc0) at gc.c:1259
  #10 0x400000000013c950 in newobj_of (klass=0, flags=40, v1=0, v2=0, v3=0) at gc.c:1303
  #11 0x400000000013ccc0 in rb_newobj_of (klass=0, flags=40) at gc.c:1356
  #12 0x4000000000163740 in hash_alloc (klass=0) at hash.c:289
  #13 0x4000000000163860 in rb_hash_new () at hash.c:309
  #14 0x400000000050e420 in Init_BareVM () at vm.c:2822
  #15 0x40000000000f6b60 in ruby_setup () at eval.c:54
  #16 0x40000000000f6f50 in ruby_init () at eval.c:75
  #17 0x400000000001b010 in main (argc=9, argv=0x60000fffffffb1d8) at main.c:35

The problem here is in call
    gc_mark_locations (objspace=0x6000000000045db0, start=0x0, end=0x6000080000000368) at gc.c:3310
where 'start' (native_main_thread.register_stack_start)
is supposed to be stack start but it's not initialized.

The initialization of 'native_main_thread.register_stack_start'
is supposed to be done in 'ruby_init_stack()'.

But code under 'MAINSTACKADDR_AVAILABLE' exits early.
The fix is to move 'register_stack_start' earlier.

Tested on the following branches: ruby-2.1, ruby-2.4, trunk.

Reported-by: Émeric Maschino
Reported-by: Maksim Derbasov
Bug: https://bugs.gentoo.org/561780
Bug: https://bugs.ruby-lang.org/issues/13284
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

trofi added a commit to trofi/ruby that referenced this pull request May 20, 2017

ia64: fix crash on register stack mark/sweep pass
The crash in ./miniruby looks like that:

  Program received signal SIGSEGV, Segmentation fault.
  mark_locations_array (objspace=0x6000000000045db0, x=0x0, n=864692227966763116) at gc.c:3297
  3297            v = *x;
  (gdb) bt
  #0  mark_locations_array (objspace=0x6000000000045db0, x=0x0, n=864692227966763116) at gc.c:3297
  #1  0x400000000014a040 in gc_mark_locations (objspace=0x6000000000045db0, start=0x0, end=0x6000080000000368) at gc.c:3310
  #2  0x400000000014b3a0 in mark_current_machine_context (objspace=0x6000000000045db0, th=0x60000000000455b0) at gc.c:3500
  #3  0x400000000014dfe0 in gc_mark_roots (objspace=0x6000000000045db0, full_mark=0, categoryp=0x0) at gc.c:4105
  #4  0x400000000014e6b0 in gc_marks_body (objspace=0x6000000000045db0, full_mark=0) at gc.c:4164
  #5  0x400000000014f260 in gc_marks (objspace=0x6000000000045db0, full_mark=0) at gc.c:4526
  #6  0x40000000001525c0 in garbage_collect_body (objspace=0x6000000000045db0, full_mark=0, immediate_sweep=0, reason=256) at gc.c:5024
  #7  0x400000000013c010 in heap_prepare_freepage (objspace=0x6000000000045db0, heap=0x6000000000045dc0) at gc.c:1219
  #8  0x400000000013c140 in heap_get_freeobj_from_next_freepage (objspace=0x6000000000045db0, heap=0x6000000000045dc0) at gc.c:1237
  #9  0x400000000013c360 in heap_get_freeobj (objspace=0x6000000000045db0, heap=0x6000000000045dc0) at gc.c:1259
  #10 0x400000000013c950 in newobj_of (klass=0, flags=40, v1=0, v2=0, v3=0) at gc.c:1303
  #11 0x400000000013ccc0 in rb_newobj_of (klass=0, flags=40) at gc.c:1356
  #12 0x4000000000163740 in hash_alloc (klass=0) at hash.c:289
  #13 0x4000000000163860 in rb_hash_new () at hash.c:309
  #14 0x400000000050e420 in Init_BareVM () at vm.c:2822
  #15 0x40000000000f6b60 in ruby_setup () at eval.c:54
  #16 0x40000000000f6f50 in ruby_init () at eval.c:75
  #17 0x400000000001b010 in main (argc=9, argv=0x60000fffffffb1d8) at main.c:35

The problem here is in call
    gc_mark_locations (objspace=0x6000000000045db0, start=0x0, end=0x6000080000000368) at gc.c:3310
where 'start' (native_main_thread.register_stack_start)
is supposed to be stack start but it's not initialized.

The initialization of 'native_main_thread.register_stack_start'
is supposed to be done in 'ruby_init_stack()'.

But code under 'MAINSTACKADDR_AVAILABLE' exits early.
The fix is to move 'register_stack_start' earlier.

Tested on the following branches: ruby-2.1, ruby-2.4, trunk.

Reported-by: Émeric Maschino
Bug: https://bugs.gentoo.org/561780
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment