[#22637] [Bug #1240] parser bug in 1.8.7 and 1.9.1p0 — Thomer Gil <redmine@...>
Bug #1240: parser bug in 1.8.7 and 1.9.1p0
Issue #1240 has been updated by Yusuke Endoh.
[#22640] [Bug #1241] Segfault with Nokogiri 1.2.1 on Ruby 1.9.1p0 — Raven Ex <redmine@...>
Bug #1241: Segfault with Nokogiri 1.2.1 on Ruby 1.9.1p0
[#22646] [Bug #1243] 1 is prime — Yuki Sonoda <redmine@...>
Bug #1243: 1 is prime
Issue #1243 has been updated by Dave B.
[#22684] [Bug #1247] YAML::load converts some dates into strings — Matthew Wilson <redmine@...>
Bug #1247: YAML::load converts some dates into strings
Issue #1247 has been updated by Yusuke Endoh.
On Thu, Apr 08, 2010 at 10:22:57PM +0900, Yusuke Endoh wrote:
On 4/8/10, Aaron Patterson <aaron@tenderlovemaking.com> wrote:
Hi,
[#22685] 1.9 conditional wait has no timeout support — Nasir Khan <rubylearner@...>
In ruby 1.8 we could use -
[#22687] [Bug #1248] e.exception(e) returns self — Tomas Matousek <redmine@...>
Bug #1248: e.exception(e) returns self
Hi,
Well the reason is that arg is supposed to be a message, right? A message can be an arbitrary object. So if I pass e as a message, why it doesn't become a value of the message property?
Hi,
[#22715] [Bug #1251] gsub problem — Alexander Pettelkau <redmine@...>
Bug #1251: gsub problem
[#22725] [Bug #1253] Fix MSVC Build Issues — Charlie Savage <redmine@...>
Bug #1253: Fix MSVC Build Issues
[#22727] Moving ruby 1.9.1 forward on windows — Charlie Savage <cfis@...>
Hi everyone,
On Sat, Mar 7, 2009 at 7:01 PM, Charlie Savage <cfis@savagexi.com> wrote:
> This works until you start linking third-party upstream source that
On Sun, Mar 8, 2009 at 3:45 PM, Charlie Savage <cfis@savagexi.com> wrote:
Hi Austin,
On Sun, Mar 8, 2009 at 4:26 PM, Charlie Savage <cfis@savagexi.com> wrote:
[#22731] [Bug #1255] += for large strings egrigiously slow — James Lee <redmine@...>
Bug #1255: += for large strings egrigiously slow
[#22736] Ruby 1.9.1 and tail recursion optimization — =?ISO-8859-15?Q?Wolfgang_N=E1dasi-Donner?= <ed.odanow@...>
Moin, moin!
Wolfgang N疆asi-Donner schrieb:
Hi,
>
On Sun, Mar 8, 2009 at 16:57, James Coglan <jcoglan@googlemail.com> wrote:
2009/3/8 Nikolai Weibull <now@bitwi.se>
James Coglan wrote:
daz schrieb:
Wolfgang N叩dasi-Donner wrote:
Charles Oliver Nutter schrieb:
[#22748] [Feature #1256] Add constant TAILRECURSION to let a program recognize if tail recursion optimization is implemented — Wolfgang Nádasi-Donner <redmine@...>
Feature #1256: Add constant TAILRECURSION to let a program recognize if tail recursion optimization is implemented
Hi,
[#22803] Relegate 1.8.6 to Engine Yard, part II — Urabe Shyouhei <shyouhei@...>
Hello and sorry for my being slow for this issue. It's OK now for me to pass
Ryan Davis wrote:
Urabe Shyouhei wrote:
Hi,
Nobuyoshi Nakada wrote:
Urabe Shyouhei wrote:
[#22812] [Bug #1261] cross-compiling Ruby extensions using mkmf doesn't fully respect DESTDIR — Daniel Golle <redmine@...>
Bug #1261: cross-compiling Ruby extensions using mkmf doesn't fully respect DESTDIR
[#22859] [Bug #1277] Incorrect passing of file handle between runtime libraries in OpenSSL extension — Charlie Savage <redmine@...>
Bug #1277: Incorrect passing of file handle between runtime libraries in OpenSSL extension
[#22892] Ruby Time — valodzka <valodzka@...>
Got tired of current ruby Time limitation, I have written this -
In article <9e19ed87-9d12-4f98-af3c-bd49a71b0bd4@p11g2000yqe.googlegroups.com>,
valodzka wrote:
> I bet you'll get tired of updating that database. There's a major difference
valodzka wrote:
In article <b5d0a489-4613-4b63-9664-8627358b2dd9@g19g2000yql.googlegroups.com>,
> I found a discussion in PHP.
In article <deab6882-12ac-4aa1-a901-681795ed863b@z9g2000yqi.googlegroups.com>,
[#22893] [Feature #1291] O_CLOEXEC flag missing for Kernel::open — David Martin <redmine@...>
Feature #1291: O_CLOEXEC flag missing for Kernel::open
Issue #1291 has been updated by Motohiro KOSAKI.
[#22894] [Bug #1292] 1.8 compile time error with mingw gcc 4.3 — Roger Pack <redmine@...>
Bug #1292: 1.8 compile time error with mingw gcc 4.3
Hi,
[#22916] [Bug #1296] [trunk/22981] 64-bit issues on trunk in ext/zlib — Ollivier Robert <redmine@...>
Bug #1296: [trunk/22981] 64-bit issues on trunk in ext/zlib
[#22927] [Bug #1301] Poor RegExp Matching Performance — Andreas Grau <redmine@...>
Bug #1301: Poor RegExp Matching Performance
[#22935] 1.8.6 rdoc breaks when rdoc'ing 1.9 — James Britt <james.britt@...>
I'm running ruby 1.8.6 (2009-03-10 patchlevel 362) [i686-linux] and
[#22937] Ruby not to be a part of Google's 2009 Summer of Code? — Rocky Bernstein <rocky.bernstein@...>
The list of participating organizations for Google's 2009 Summer of Code has
[#22978] Ruby 1.9 bloc parameters — Vincent Isambart <vincent.isambart@...>
Hi,
[#22979] Ruby 1.9 bloc parameters — Vincent Isambart <vincent.isambart@...>
Hi,
[#22990] [Bug #1309] dl tests — Charlie Savage <redmine@...>
Bug #1309: dl tests
[#23026] [Bug #1317] Creating a range with strings — Ian Bailey <redmine@...>
Bug #1317: Creating a range with strings
[#23050] [Bug #1322] define_method scope bug — "coderrr ." <redmine@...>
Bug #1322: define_method scope bug
[#23051] [Bug #1323] Sockets broken on windows — Charlie Savage <redmine@...>
Bug #1323: Sockets broken on windows
[#23053] [Bug #1325] fiber tests kill windows — Charlie Savage <redmine@...>
Bug #1325: fiber tests kill windows
[#23054] [Bug #1326] Failing unit tests on windows — Charlie Savage <redmine@...>
Bug #1326: Failing unit tests on windows
[#23060] [Bug #1327] CSV unit test failures on windows — Charlie Savage <redmine@...>
Bug #1327: CSV unit test failures on windows
[#23063] [Bug #1332] Reading file on Windows is 500x slower then with previous Ruby version — Damjan Rems <redmine@...>
Bug #1332: Reading file on Windows is 500x slower then with previous Ruby version
Issue #1332 has been updated by Roger Pack.
Hello,
[#23075] [Bug #1336] Change in string representation of Floats — Brian Ford <redmine@...>
Bug #1336: Change in string representation of Floats
Issue #1336 has been updated by Roger Pack.
On Fri, Apr 3, 2009 at 11:49 PM, Roger Pack <redmine@ruby-lang.org> wrote:
Issue #1336 has been updated by Roger Pack.
Hi,
Hi,
Hi,
Gary Wright wrote:
[#23082] [Bug #1341] pthread_cond_timedwait failing in 1.9.1-p0 thread tests — Graham Agnew <redmine@...>
Bug #1341: pthread_cond_timedwait failing in 1.9.1-p0 thread tests
[ruby-core:22633] [Bug #1239] build fails for OpenBSD: [BUG] register_sigaltstack. error
Bug #1239: build fails for OpenBSD: [BUG] register_sigaltstack. error
http://redmine.ruby-lang.org/issues/show/1239
Author: George Koehler
Status: Open, Priority: Normal
ruby -v: ruby 1.9.1p0 (2009-01-30 revision 21907) [powerpc-openbsd4.5]
I have a computer with OpenBSD and I tried Ruby 1.9.1. So I obtained the source code, configured with "../configure --prefix=$HOME/prefix" and did "make". The build failed with an error. My computer has a PowerPC processor and the operating system is OpenBSD 4.5-beta.
Here I use "make -dl" to show the miniruby command causing the error:
<pre>
$ make -dl
./miniruby -I./lib -I.ext/common -I./- -r./ext/purelib.rb ./mkconfig.rb -timestamp=./.rbconfig.time -install_name=ruby -so_name=ruby rbconfig.rb
[BUG] register_sigaltstack. error
ruby 1.9.1p0 (2009-01-30 revision 21907) [powerpc-openbsd4.5]
-- control frame ----------
c:0001 p:---- s:0002 b:0002 l:000001 d:000001 TOP
---------------------------
Segmentation fault (core dumped)
*** Error code 139
Stop in /home/kernigh/park/ruby-wrong/ruby-1.9.1-p0 (line 691 of Makefile).
</pre>
The same error happens if I do "./miniruby" with no arguments.
I looked in the Ruby source code. I found that "register_sigaltstack. error" happens if the call to sigaltstack() fails. So I searched for why sigaltstack() fails. I found the answer in the source code of the OpenBSD pthreads library.
OpenBSD does not have kernel threads. The OpenBSD pthreads library implements threads in userspace. (OpenBSD is the only operating system, that I know, where pthreads are not kernel threads. They say that Ruby 1.9 uses kernel threads, but this is not true for OpenBSD!) The OpenBSD pthreads library does override multiple libc functions, including sigaltstack().
Here is the comment in OpenBSD src/lib/libpthread/uthread/uthread_sigaltstack.c
<pre>
/*
* IEEE Std 1003.1-2001 says:
*
* "Use of this function by library threads that are not bound to
* kernel-scheduled entities results in undefined behavior."
*
* There exists code (e.g. alpha setjmp) that uses this function
* to get information about the current stack.
*
* The "undefined behaviour" in this implementation is thus:
* o if ss is *not* null return -1 with errno set to EINVAL
* o if oss is *not* null fill it in with information about the
* current stack and return 0.
*
* This lets things like alpha setjmp work in threaded applications.
*/
int
sigaltstack(const struct sigaltstack *ss, struct sigaltstack *oss)
{
struct pthread *curthread = _get_curthread();
int ret = 0;
if (ss != NULL) {
errno = EINVAL;
ret = -1;
} else ...
</pre>
So the OpenBSD pthreads library does not allow a separate signal stack. Whenever you give a signal stack to sigaltstack(), it always returns EINVAL.
So I changed my copy of ruby-1.9.1-p0/signal.c to ignore this error.
<pre>
--- signal.c.orig Wed Jan 28 04:22:07 2009
+++ signal.c Mon Mar 2 14:11:01 2009
@@ -444,8 +444,13 @@
newSS.ss_size = ALT_STACK_SIZE;
newSS.ss_flags = 0;
- if (sigaltstack(&newSS, &oldSS) < 0)
- rb_bug("register_sigaltstack. error\n");
+ if (sigaltstack(&newSS, &oldSS) < 0) {
+ if (errno == EINVAL) {
+ /* ignore error, always happens with OpenBSD pthreads */
+ }
+ else
+ rb_bug("register_sigaltstack. error\n");
+ }
}
#endif
</pre>
I left in the call to sigaltstack(), in case OpenBSD ever fixes their broken sigaltstack() function, but I ignored the EINVAL error. (Other ways might be to put an #ifdef __OpenBSD__ somewhere, or to #undef HAVE_SIGALTSTACK with OpenBSD.)
After I made this change to signal.c, I did "make", "make test" and "make install". Ruby seems to work correctly. All tests pass except one test in test_objectspace.rb, that seems to do an infinite loop, so I had to Control-C that test.
<pre>
#703 test_objectspace.rb:13:in `<top (required)>': [ruby-dev:31911]
FAIL 1/928 tests failed
</pre>
I agree when ruby-1.9.1-p0/README claims that ruby is "Highly Portable". Except for one call to sigaltstack(), everything in Ruby 1.9.1 seems to work with OpenBSD. Though the Ruby manual pages do have a few tiny formatting mistakes, but I will not worry about that until later. I wonder if someone will fix how Ruby uses sigaltstack().
----------------------------------------
http://redmine.ruby-lang.org