[#80974] [Ruby trunk Feature#13517] [PATCH] reduce rb_mutex_t size from 160 to 80 bytes on 64-bit — ko1@...
Issue #13517 has been updated by ko1 (Koichi Sasada).
4 messages
2017/05/02
[#81024] Re: [Ruby trunk Feature#13517] [PATCH] reduce rb_mutex_t size from 160 to 80 bytes on 64-bit
— SASADA Koichi <ko1@...>
2017/05/07
sorry for late response.
[#80996] [Ruby trunk Feature#13544] Allow loading an ISeqs sequence directly from a C extension without requiring buffer is in an RVALUE — sam.saffron@...
Issue #13544 has been reported by sam.saffron (Sam Saffron).
3 messages
2017/05/04
[#81016] [Ruby trunk Bug#13526] Segmentation fault at 0x0055c2e58e8920 ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-linux] — s.wanabe@...
Issue #13526 has been updated by wanabe (_ wanabe).
3 messages
2017/05/07
[#81048] Re: [ruby-cvs:65788] normal:r58614 (trunk): rb_execution_context_t: move stack, stack_size and cfp from rb_thread_t — SASADA Koichi <ko1@...>
It causes compile error on raspi 3.
3 messages
2017/05/09
[#81201] Re: [ruby-cvs:65935] normal:r58761 (trunk): test/test_extilibs.rb: do not check the existence of fiddle — "U.NAKAMURA" <usa@...>
Hi, Eric
4 messages
2017/05/16
[#81202] Re: [ruby-cvs:65935] normal:r58761 (trunk): test/test_extilibs.rb: do not check the existence of fiddle
— Eric Wong <normalperson@...>
2017/05/16
"U.NAKAMURA" <usa@garbagecollect.jp> wrote:
[#81427] Fwd: [ruby-changes:46809] normal:r58924 (trunk): test for IO.copy_stream CPU usage (r58534) — SASADA Koichi <ko1@...>
Hi,
6 messages
2017/05/28
[#81428] Re: Fwd: [ruby-changes:46809] normal:r58924 (trunk): test for IO.copy_stream CPU usage (r58534)
— Eric Wong <normalperson@...>
2017/05/28
SASADA Koichi <ko1@atdot.net> wrote:
[ruby-core:81084] [Ruby trunk Bug#13554] Running system with different gid fails on Linux if host has group with lots of members
From:
ssgelm@...
Date:
2017-05-10 04:19:54 UTC
List:
ruby-core #81084
Issue #13554 has been reported by ssgelm (Stephen Gelman).
----------------------------------------
Bug #13554: Running system with different gid fails on Linux if host has group with lots of members
https://bugs.ruby-lang.org/issues/13554
* Author: ssgelm (Stephen Gelman)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
* ruby -v: ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-linux]
* Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
In #9600, it was pointed out that groups can be larger than sysconf(SC_GETGR_R_SIZE_MAX) in Linux. This was fixed in r45290 by enlarging the buffer and retrying. That worked well, but it was broken again in r51492. Ever since, when trying to run the following ruby code:
~~~ ruby
begin
system("/bin/ls", gid: "adm")
rescue => exception
puts exception.backtrace
raise
end
~~~
I get the backtrace:
~~~
gid.rb:2:in `system'
gid.rb:2:in `<main>'
gid.rb:2:in `system': can't modify frozen false (RuntimeError)
from gid.rb:2:in `<main>'
~~~
In this case the "adm" group has about 200 members. It's worth noting that because of the way getgrnam_r works this happens if I pick any group listed after adm. It seems that the change in r51492 causes the buffer that is allocated for getgrnam_r to be marked as frozen, so when it's not big enough and it gets resized using rb_str_modify_expand ruby raises an exception.
This occurs in any release of ruby 2.3 or 2.4 and also on the trunk on either debian wheezy or jessie.
I don't have a deep enough knowledge of the ruby C API to know the best fix, but I was able to work around the problem with the following change:
~~~
diff --git a/process.c b/process.c
index 9191051..721dd4c 100644
--- a/process.c
+++ b/process.c
@@ -5126,9 +5126,9 @@ obj2gid(VALUE id
rb_free_tmp_buffer(getgr_tmp);
rb_syserr_fail(e, "getgrnam_r");
}
- rb_str_modify_expand(*getgr_tmp, getgr_buf_len);
- getgr_buf = RSTRING_PTR(*getgr_tmp);
- getgr_buf_len = rb_str_capacity(*getgr_tmp);
+ rb_free_tmp_buffer(getgr_tmp);
+ getgr_buf_len = getgr_buf_len * 2;
+ getgr_buf = rb_alloc_tmp_buffer(getgr_tmp, getgr_buf_len);
}
#elif defined(HAVE_GETGRNAM)
grptr = getgrnam(grpname);
~~~
Alternatively, I assume the better way to fix this would be to allocate the tmp buffer in a way that allows it to be resized but I didn't see an obvious way to do that.
--
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>