[#42] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...>

32 messages 2002/05/25
[#43] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/26

Hi,

[#45] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/26

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#46] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/26

Hi,

[#47] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/26

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#48] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/26

>>>>> "t" == ts <decoux@moulon.inra.fr> writes:

[#49] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/27

Hi,

[#50] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/27

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#51] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/27

Hi,

[#52] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/27

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#53] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/27

Hi,

[#54] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/27

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#55] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/27

Hi,

[#56] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/27

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#57] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/28

Hi,

[#65] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/28

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#84] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/29

Hi,

[#92] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/29

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#67] The warns-a-thon continues... — Sean Chittenden <sean@...>

I'm feeling left out in this race to clobber warnings!!! Attached are

19 messages 2002/05/28

[#104] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...>

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

29 messages 2002/05/30
[#105] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/30

Hi,

[#125] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/06/04

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#126] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/06/04

Hi,

[#127] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/06/04

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#130] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/06/04

Hi,

[#132] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/06/05

Hi,

[#134] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/06/05

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

Re: [BUG] thread failure after trap

From: ts <decoux@...>
Date: 2002-05-16 05:26:39 UTC
List: ruby-core #20
>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

n> Sure.  But I wonder if other values should be preserved.

 If I've well understood, a signal is always run in the main thread.

 After the signal, ruby must give the control to the current thread (the
 thread which has received the signal) because this thread need to test if
 some others signals are pending and it must restore the old value for the
 main thread.

pigeon% diff -u eval.c.old eval.c
--- eval.c.old  Thu May 16 06:58:11 2002
+++ eval.c      Thu May 16 06:59:08 2002
@@ -7422,6 +7422,8 @@
 static int   th_sig;
 static char *th_signm;
 
+static rb_thread_t th_thread;
+
 #define RESTORE_NORMAL         1
 #define RESTORE_FATAL          2
 #define RESTORE_INTERRUPT      3
@@ -7477,6 +7479,8 @@
     th->line = ruby_sourceline;
 }
 
+static void rb_thread_restore_context _((rb_thread_t,int));
+
 static int
 thread_switch(n)
     int n;
@@ -7493,6 +7497,10 @@
       case RESTORE_TRAP:
        rb_trap_eval(th_cmd, th_sig);
        errno = EINTR;
+       if (th_thread) {
+           curr_thread = th_thread;
+           rb_thread_restore_context(curr_thread, RESTORE_NORMAL);
+       }
        break;
       case RESTORE_RAISE:
        ruby_frame->last_func = 0;
@@ -7513,8 +7521,6 @@
 #define THREAD_SAVE_CONTEXT(th) \
     (rb_thread_save_context(th),thread_switch(setjmp((th)->context)))
 
-static void rb_thread_restore_context _((rb_thread_t,int));
-
 static void
 stack_extend(th, exit)
     rb_thread_t th;
@@ -8839,6 +8845,8 @@
     VALUE cmd;
     int sig;
 {
+    volatile int status;
+    volatile int wait_for;
 #if 0
     rb_thread_critical = 0;
     if (!rb_thread_dead(curr_thread)) {
@@ -8856,8 +8864,14 @@
     rb_thread_restore_context(curr_thread, RESTORE_TRAP);
 #else
     rb_thread_critical = 0;
+    th_thread = 0;
     if (!rb_thread_dead(curr_thread)) {
+       th_thread = curr_thread;
+       status = main_thread->status;
+       wait_for = main_thread->wait_for;
        if (THREAD_SAVE_CONTEXT(curr_thread)) {
+           main_thread->status = status;
+           main_thread->wait_for = wait_for;
            return;
        }
     }
pigeon% 



Guy Decoux

In This Thread