With this configuration
obsd% ./ruby -v
ruby 1.9.0 (2004-04-07) [sparc-openbsd3.4]
obsd%
it’s normal that ruby use _setjmp()/_longjmp() rather than
setjmp()/longjmp() ?
Guy Decoux
With this configuration
obsd% ./ruby -v
ruby 1.9.0 (2004-04-07) [sparc-openbsd3.4]
obsd%
it’s normal that ruby use _setjmp()/_longjmp() rather than
setjmp()/longjmp() ?
Guy Decoux
Hi,
In message “OpenBSD / Sparc” on 04/04/08, ts decoux@moulon.inra.fr writes:
With this configuration
obsd% ./ruby -v
ruby 1.9.0 (2004-04-07) [sparc-openbsd3.4]
obsd%it’s normal that ruby use _setjmp()/_longjmp() rather than
setjmp()/longjmp() ?
Yes, Ruby uses _setjmp()/_longjmp() where available, because we need
not to save signal context. Is there any problem?
matz.
Yes, Ruby uses _setjmp()/_longjmp() where available, because we need
not to save signal context. Is there any problem?
Just a small problem
obsd% cat b.rb
#!./ruby
require 'timeout'
Timeout::timeout(5) { p 45 }
obsd%
obsd% ~/local/r19/bin/ruby -v b.rb
ruby 1.9.0 (2004-04-07) [sparc-openbsd3.4]
longjmp botch.
Illegal instruction (core dumped)
obsd%
obsd% diff -u eval.c.~1.657.~ eval.c
--- eval.c.~1.657.~ Wed Apr 7 08:30:13 2004
+++ eval.c Thu Apr 8 15:10:02 2004
@@ -111,7 +111,7 @@
#else
typedef jmp_buf rb_jmpbuf_t;
#ifndef setjmp
-#ifdef HAVE__SETJMP
+#ifdef HAVE___SETJMP
#define setjmp(env) _setjmp(env)
#define longjmp(env,val) _longjmp(env,val)
#endif
obsd%
obsd% ./ruby b.rb
45
obsd%
Now on OpenBSD _setjmp() dont save signal context
The setjmp()/longjmp() function pairs save and restore the signal mask
while _setjmp()/_longjmp() function pairs save and restore only the reg-
ister set and the stack (see sigmask(3)).
Guy Decoux
Yes, Ruby uses _setjmp()/_longjmp() where available, because we need
not to save signal context. Is there any problem?
Well, the problem is perhaps in OpenBSD. One day, perhaps, I'll try with
NetBSD ...
Guy Decoux
Just a small problem
Well, I can even make work this
obsd% cat c.rb
#!./ruby
require 'net/http'
Net::HTTP.start('moulon.inra.fr', 80) do |http|
r = http.get('/')
p r
end
obsd%
obsd% ./ruby -v c.rb
ruby 1.9.0 (2004-04-07) [sparc-openbsd3.4]
#<Net::HTTPOK 200 OK readbody=true>
obsd%
obsd% ~/local/r19/bin/ruby -v c.rb
ruby 1.9.0 (2004-04-07) [sparc-openbsd3.4]
longjmp botch.
Illegal instruction (core dumped)
obsd%
And with the version of ruby which is in the packages
(http://www.openbsd.org/3.4_packages/sparc.html\)
i.e. not compiled by me
obsd% /usr/local/bin/ruby -v c.rb
ruby 1.6.8 (2002-12-24) [sparc-openbsd3.4]
longjmp botch.
Illegal instruction (core dumped)
obsd%
You can't trust "anglois" to compile a program
Guy Decoux
In Message-Id: 200404081501.i38F10f20125@moulon.inra.fr
ts decoux@moulon.inra.fr writes:
You can’t trust “anglois” to compile a program
Well… just an idea that can be nothing to do with the problem but
did you compiled all version of ruby with same compiler option? My
memory says at least OpenBSD ports can be compiled with stack
protection, and that may cause the problem…
–
kjana@dm4lab.to April 11, 2004
Time is illusion, life is confusion.
Well.... just an idea that can be nothing to do with the problem but
did you compiled all version of ruby with same compiler option? My
memory says at least OpenBSD ports can be compiled with stack
protection, and that may cause the problem....
Well, NetBSD and OpenBSD use the same setjmp()/longjmp(), but this is not
true for _setjmp()/_longjmp().
NetBSD use the revision 1.7 with this comment for 1.6
CVS log for src/lib/libc/arch/sparc/gen/_setjmp.S
A new implementation of _setjmp/_longjmp that uses the T_FLUSHWIN trap.
This means the stack frame and program counter can restored directly
from the jmp_buf, eliminating the need to backtrack through frames
which does not work in all cases.
OpenBSD use the revision 1.5
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/arch/sparc/gen/_setjmp.S
and when you look at its algorithm, you understand why it can have
problem ...
Guy Decoux