Re: i guess we're frozen & stuff

[Neil Jerram <neil@ossau.uklinux.net>]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi,
>
> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>
>>> This must be related to http://savannah.gnu.org/bugs/?27457 .
>>> Contributions welcome!  ;-)
>>
>> I will start looking at this later this evening.  (Unless you're already
>> investigating - in which case please let me know!)
>
> I won’t look into it in the next days, so go ahead!  ;-)

Well...  I don't see the throw from critical section problem.  Instead,
after a while, I see a hang, with one thread doing:

#0  0xb7f06424 in __kernel_vsyscall ()
#1  0xb7acd255 in sem_wait@@GLIBC_2.1 () from /lib/i686/cmov/libpthread.so.0
#2  0xb7dc2018 in GC_stop_world () from /usr/lib/libgc.so.1

and all the others:

#0  0xb7f06424 in __kernel_vsyscall ()
#1  0xb7b05837 in sigsuspend () from /lib/i686/cmov/libc.so.6
#2  0xb7dc222b in GC_suspend_handler_inner () from /usr/lib/libgc.so.1
#3  0xb7dc22b5 in GC_suspend_handler () from /usr/lib/libgc.so.1
#4  <signal handler called>

In theory, each other thread must have called sem_post(), and the number
of those sem_post()s should be the same as the number of times that the
GC_stop_world thread calls sem_wait(), and so the GC_stop_world thread
shouldn't be waiting.

I wonder if there's a way that the pthread_kill(p->id, SIG_SUSPEND) in
GC_stop_world can appear to succeed (by returning 0), but the signalled
thread doesn't get the signal, or dies before it does the sem_post()?

Regarding the throw from critical section problem, I guess I'm not
seeing this because of not running on a multi-core machine.  Can someone
who does see this problem

- run under GDB
- set a breakpoint on the fprintf (stderr, "throw from within critical
  section.\n") line in throw.c
- post the thread backtraces (thread apply all bt), when this breakpoint
  is hit?

Thanks.

        Neil