[#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!

8 messages 2009/04/17

[#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)

19 messages 2009/04/26

[ruby-core:23340] [Bug #1388] cygwin-1.7, gcc4-4.3, and ruby-1.9. make btest #236 test_io.rb Segmentation fault

From: neomjp neomjp <redmine@...>
Date: 2009-04-30 15:57:41 UTC
List: ruby-core #23340
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

In This Thread

Prev Next