[#112457] [Ruby master Feature#19443] Cache `Process.pid` — "byroot (Jean Boussier) via ruby-core" <ruby-core@...>
Issue #19443 has been reported by byroot (Jean Boussier).
16 messages
2023/02/16
[#112584] [Ruby master Feature#19465] [PATCH] reuse open(2) from rb_file_load_ok on POSIX-like system — "normalperson (Eric Wong) via ruby-core" <ruby-core@...>
Issue #19465 has been reported by normalperson (Eric Wong).
9 messages
2023/02/25
[#112595] [Ruby master Feature#19465] [PATCH] reuse open(2) from rb_file_load_ok on POSIX-like system
— "nobu (Nobuyoshi Nakada) via ruby-core" <ruby-core@...>
2023/02/25
SXNzdWUgIzE5NDY1IGhhcyBiZWVuIHVwZGF0ZWQgYnkgbm9idSAoTm9idXlvc2hpIE5ha2FkYSku
[#112613] Re: [Ruby master Feature#19465] [PATCH] reuse open(2) from rb_file_load_ok on POSIX-like system
— Eric Wong via ruby-core <ruby-core@...>
2023/02/26
"nobu (Nobuyoshi Nakada) via ruby-core" <ruby-core@ml.ruby-lang.org> wrote:
[#112615] Re: [Ruby master Feature#19465] [PATCH] reuse open(2) from rb_file_load_ok on POSIX-like system
— SHIBATA Hiroshi via ruby-core <ruby-core@...>
2023/02/27
MzUxMzZlMWU5YzIzMmFkN2EwMzQwN2I5OTJiMmU4NmI2ZGY0M2Y2MyBpcyBicm9rZW4gd2l0aCBg
[#112626] Re: [Ruby master Feature#19465] [PATCH] reuse open(2) from rb_file_load_ok on POSIX-like system
— Eric Wong via ruby-core <ruby-core@...>
2023/02/28
```
[ruby-core:112181] [Ruby master Bug#19397] ruby -h fails with SIGSGV if ulimit -s is any else than unlimited
From:
"john_d_s (John Damm Soerensen) via ruby-core" <ruby-core@...>
Date:
2023-02-02 09:33:47 UTC
List:
ruby-core #112181
Issue #19397 has been updated by john_d_s (John Damm Soerensen).
We see it on all of our systems.
But it gets stranger as it turns out to only happen in an interactive shell and not when executed in a shell script.
Furthermore it seems to only happen with certain combinations of soft and hard limits, though I have figured out which, but 8192/8192 also works on our systems.
For reference the build was done as per instruction in the ./doc/contributing/building_ruby.md
I have looked at the offending code in thread_pthread.c and it is using alloca() which use according to the manual is highly discouraged.
Since the code is only invoked in cases where the stack limit is not unlimited/infinity it seems not to be needed. Therefor I suggest that to consider removing the code.
Anyway we have a workaround and you can close the case.
----------------------------------------
Bug #19397: ruby -h fails with SIGSGV if ulimit -s is any else than unlimited
https://bugs.ruby-lang.org/issues/19397#change-101618
* Author: john_d_s (John Damm Soerensen)
* Status: Feedback
* Priority: Normal
* ruby -v: ruby 3.3.0dev (2023-01-30T23:43:40Z master 7439ccf0ed) [x86_64-linux]
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
This applies to all versions of ruby.
I have tried these 2.6.3 2.6.6 2.7.2 3.0.0 3.2.0
To reproduce simply set `ulimit -s` to anything other than unlimited.
Then run `ruby -h` (or any other invocation of ruby) and ruby will generate a SIGSEGV and core dump.
The stack trace from gdb shows that ruby has failed in reserve_stack line 1022 (for the latest from github)
gdb ruby core.11885
```
Core was generated by `./ruby -h'.
Program terminated with signal 11, Segmentation fault.
#0 reserve_stack (limit=0x7e9a5f4400e0 <Address 0x7e9a5f4400e0 out of bounds>,
limit@entry=0x7fffffffe000 "l=38;5;13:*.xcf=38;5;13:*.xwd=38;5;13:*.yuv=38;5;13:*.cgm=38;5;13:*.emf=38;5;13:*.axv=38;5;13:*.anx=38;5;13:*.ogv=38;5;13:*.ogx=38;5;13:*.aac=38;5;45:*.au=38;5;45:*.flac=38;5;45:*.mid=38;5;45:*.midi=3"..., size=1535999991552, size@entry=1535999995904)
at thread_pthread.c:1022
1022 limit[0] = 0;
```
--
https://bugs.ruby-lang.org/
______________________________________________
ruby-core mailing list -- ruby-core@ml.ruby-lang.org
To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/