[#23132] [Bug #1357] Fixing variables into specific CPU registers deemed overrated & may disturb compilers' optimizers — Ollivier Robert <redmine@...>
Bug #1357: Fixing variables into specific CPU registers deemed overrated & may disturb compilers' optimizers
[#23154] [Bug #1363] Wrong value for Hash of NaN — Heesob Park <redmine@...>
Bug #1363: Wrong value for Hash of NaN
Hi,
Hi,
Yukihiro Matsumoto wrote:
[#23168] [Bug #1367] flatten(0) is not consistent with flatten(), flatten(1), etc. — Paul Lewis <redmine@...>
Bug #1367: flatten(0) is not consistent with flatten(), flatten(1), etc.
Issue #1367 has been updated by Paul Lewis.
[#23174] [Feature #1371] FTPS Implicit — Daniel Parker <redmine@...>
Feature #1371: FTPS Implicit
[#23193] Regexp Encoding — James Gray <james@...>
I'm trying to document the Encoding Regexp objects receive for the
[#23194] [Feature #1377] Please provide constant File::NOATIME — Johan Walles <redmine@...>
Feature #1377: Please provide constant File::NOATIME
[#23231] What do you think about changing the return value of Kernel#require and Kernel#load to the source encoding of the required file? — =?ISO-8859-15?Q?Wolfgang_N=E1dasi-Donner?= <ed.odanow@...>
Dear Ruby developers and users!
Wolfgang N叩dasi-Donner wrote:
Wolfgang N叩dasi-Donner wrote:
Michael Neumann schrieb:
[#23252] [Bug #1392] Object#extend leaks memory on Ruby 1.9.1 — Muhammad Ali <redmine@...>
Bug #1392: Object#extend leaks memory on Ruby 1.9.1
[#23267] StringIO: RubySpec violation — Hongli Lai <hongli@...99.net>
I ran RubySpec against the 1.8.6-p368 release. It seems that
[#23289] [Bug #1399] Segmentation fault is raised when you use a postgres gem — Marcel Keil <redmine@...>
Bug #1399: Segmentation fault is raised when you use a postgres gem
[#23297] Ruby Oniguruma question — Ralf Junker <ralfjunker@...>
I see that the Ruby source code contains modified and more recent version of the Oniguruma regular expression library.
[#23305] [Bug #1403] Process.daemon should do a double fork to avoid problems with controlling terminals — Gary Wright <redmine@...>
Bug #1403: Process.daemon should do a double fork to avoid problems with controlling terminals
Hi,
[#23311] [Bug #1404] Net::HTTP::Post failing when a post field contains ":" — Ignacio Martín <redmine@...>
Bug #1404: Net::HTTP::Post failing when a post field contains ":"
[#23318] [Feature #1408] 0.1.to_r not equal to (1/10) — Heesob Park <redmine@...>
Feature #1408: 0.1.to_r not equal to (1/10)
Issue #1408 has been updated by tadayoshi funaba.
Hi,
Hi.
Issue #1408 has been updated by Marc-Andre Lafortune.
Issue #1408 has been updated by Roger Pack.
[#23321] [Bug #1412] 1.8.7-p160 extmk.rb fails when cross compiling — Luis Lavena <redmine@...>
Bug #1412: 1.8.7-p160 extmk.rb fails when cross compiling
[ruby-core:23340] [Bug #1388] cygwin-1.7, gcc4-4.3, and ruby-1.9. make btest #236 test_io.rb Segmentation fault
Issue #1388 has been updated by neomjp neomjp.
Thanks for the quick and thorough review. I am sorry that I could not
report back earlier.
On 2009/04/19 20:12, Nobuyoshi Nakada wrote:
> At Sat, 18 Apr 2009 04:56:10 +0900,
> neomjp neomjp wrote in [ruby-core:23241]:
>> -#ifdef __CYGWIN__
>> -int _setjmp(), _longjmp();
>> -#endif
>
> The definitions seem just with extern and arguments, and above
> declaration doesn't seem conflict with them, what error does
> occur?
In file included from .../ruby-1.9.2-r23198/eval.c:14:
.../ruby-1.9.2-r23198/eval_intern.h:70: error: conflicting types for '_longjmp'
/usr/include/machine/setjmp.h:318: error: previous declaration of '_longjmp' was here
make: *** [eval.o] Error 1
Conficting part is _longjmp. Here is the relevant part of setjmp.h from
cygwin-1.7 .
$ cygcheck -f /usr/include/machine/setjmp.h
cygwin-1.7.0-46
$ sed -n 317,323p /usr/include/machine/setjmp.h
#ifdef __CYGWIN__
extern void _longjmp(jmp_buf, int);
extern int _setjmp(jmp_buf);
#else
#define _setjmp(env) sigsetjmp ((env), 0)
#define _longjmp(env, val) siglongjmp ((env), (val))
#endif
In contrast, cygwin-1.5 did not have _setjmp or _longjmp
$ cygcheck -f /usr/include/machine/setjmp.h
cygwin-1.5.25-15
$ grep -Ecr --include=setjmp* "_longjmp|_setjmp" /usr/include/
/usr/include/machine/setjmp-dj.h:0
/usr/include/machine/setjmp.h:0
/usr/include/setjmp.h:0
>> - if (cygwin_conv_to_posix_path(p, rubylib) == 0)
>> + if (cygwin_conv_path(CCP_WIN_W_TO_POSIX | CCP_RELATIVE, p, rubylib, 1)
>> + == 0)
>
> I suspect it should use CCP_WIN_A_TO_POSIX and sizeof(rubylib)
> instead of 1, am I wrong?
You are totally right. Stupid me, I just read "If size is 0 ...
Otherwise, ...", and set it to a non-zero value.
> Previously, it couldn't work with THREAD_MODEL=win32, maybe
> something improved with cygwin 1.7?
I investigated this furthur, and found that it is probably not the
case. This Makefile variable THREAD_MODEL is used in two places in
(un)common.mk, the variable VM_CORE_H_INCLUDES and the prerequisite for
thread.o:
VM_CORE_H_INCLUDES = {$(VPATH)}vm_core.h {$(VPATH)}vm_opts.h \
{$(VPATH)}thread_$(THREAD_MODEL).h \
{$(VPATH)}node.h $(ID_H_INCLUDES)
thread.$(OBJEXT): {$(VPATH)}thread.c {$(VPATH)}eval_intern.h \
$(RUBY_H_INCLUDES) {$(VPATH)}gc.h $(VM_CORE_H_INCLUDES) \
{$(VPATH)}debug.h {$(VPATH)}thread_$(THREAD_MODEL).c
So, the variable THREAD_MODEL is not used in any rules.
thread_$(THREAD_MODEL).c is #included from thread.c like this:
#if defined(_WIN32)
#include "thread_win32.c"
................................
#elif defined(HAVE_PTHREAD_H)
#include "thread_pthread.c"
....................................
#else
#error "unsupported thread type"
#endif
But in cygwin, _WIN32 is undefined, and HAVE_PTHREAD_H is defined. So
thread_pthread.c is included. If I run the preprocessoer like
gcc-4 -v -E -O2 -pipe -I. -I.ext/include/i386-cygwin
-I.../ruby-1.9.2-r23311/include -I.../ruby-1.9.2-r23311 -DRUBY_EXPORT
-o thread.o -c .../ruby-1.9.2-r23311/thread.c
This gives:
/usr/lib/gcc/i686-pc-cygwin/4.3.2/cc1.exe ... -D__CYGWIN32__
-D__CYGWIN__ -Dunix -D__unix__ -D__unix ...
and
static void timer_thread_function(void *);
# 182 ".../ruby-1.9.2-r23311/thread.c"
# 1 ".../ruby-1.9.2-r23311/thread_pthread.c" 1
# 17 ".../ruby-1.9.2-r23311/thread_pthread.c"
# 1 "/usr/include/sys/resource.h" 1 3 4
# 41 "/usr/include/sys/resource.h" 3 4
typedef unsigned long rlim_t;
....
Note that thread_pthread.c is #included instead of thread_win32.c.
So what happens with
CC=gcc-4 configure --program-suffix="-19" --disable-pthread
make THREAD_MODEL=w32
is
1. thread_pthread.c is #included from thread.c. (not thread_win32.c)
2. Objects are linked without -lpthread.
What kind of thread is working here? Anyway, both with/without
--disable-pthread passed test_thread.rb in make btest. .
> make run is supporsed to run your own script, so test.rb is a
> file which you should make. test-sample is what you want.
I see. "make test-sample" passes without errors, both with/without
--disable-pthread.
>> #236 test_io.rb:
> Segfaults in the at_exit block. I'll investigate it.
Thanks.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/1388
----------------------------------------
http://redmine.ruby-lang.org