Re: Threads

[Jon TURNEY <jon.turney@dronecode.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]

On 23/10/2014 16:37, Corinna Vinschen wrote:
> On Oct 23 08:04, Ken Brown wrote:
>> On 10/23/2014 7:31 AM, Jon TURNEY wrote:
>>> On 20/10/2014 14:03, Ken Brown wrote:
>>>> Or is there some other plausible explanation for "impossible" crashes?
>>>> This can't just be a result of a gdb bug, because in at least one case
>>>> the assertion can be shown to be valid by using printf instead of gdb.
>>>>
>>>> [*] By "impossible" I mean that examination of the relevant variables in
>>>> gdb shows that the assertions are in fact true.  Two ongoing examples are
>>>>
>>>>     http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18438
>>>>     http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18769
>>>
>>> As a suggestion, you might want to also take a careful look at how signal
>>> delivery is implemented in cygwin on x86_64
>>>
>>> I had a vague idea that there was, at some time in the past, a fix made for
>>> register corruption on x86_64 after a signal was handled, but I can't find it
>>> now, so maybe I imagined it.
>>
>> Is this what you're thinking of?
>>
>>    https://cygwin.com/ml/cygwin-cvs/2014-q1/msg00020.html
>>
>>> But if for e.g. the flags register was getting
>>> corrupted when a signal interrupts the main thread, that could perhaps also
>>> explain what is being seen.
>>
>> Yes, flags register corruption is exactly what Eli suggested in the other
>> bug report I cited.
>
> The aforementioned patch was supposed to fix this problem and it is
> definitely in the current 1.7.32 release...

I didn't mean to suggest otherwise, just that perhaps a similar problem 
exists now.

So I made the attached test case to explore that.  Maybe I've made an 
obvious mistake with it, but on the face of it, it seems to demonstrate 
something...

jon@tambora /
$ gcc signal-stress.c  -Wall -O0 -g

jon@tambora /
$ ./a
failed: 2144210386 isn't equal to 2144210386, apparently

Note there is some odd load dependency. For me, it works fine when it's 
the only thing running, but when I start up something CPU intensive, it 
often fails...

[-- Attachment #2: signal-stress.c --]
[-- Type: text/plain, Size: 1208 bytes --]


#include <assert.h>
#include <sys/time.h>
#include <signal.h>
#include <stdio.h>

long SmartScheduleInterval = 1; /* ms */
long SmartScheduleTime = 0;

static void
SmartScheduleTimer(int sig)
{
    if (sig != 0)
       SmartScheduleTime += SmartScheduleInterval;
}

void
SmartScheduleStartTimer(void)
{
    struct itimerval timer;
    timer.it_interval.tv_sec = 0;
    timer.it_interval.tv_usec = SmartScheduleInterval * 1000;
    timer.it_value.tv_sec = 0;
    timer.it_value.tv_usec = SmartScheduleInterval * 1000;
    setitimer(ITIMER_REAL, &timer, 0);
}

int main()
{
    /* Set up the timer signal function */
    struct sigaction act;
    act.sa_handler = SmartScheduleTimer;
    sigemptyset(&act.sa_mask);
    sigaddset(&act.sa_mask, SIGALRM);
    if (sigaction(SIGALRM, &act, 0) < 0) {
        perror("sigaction failed");
	return -1;
    }

   /* start timer */
   SmartScheduleStartTimer();

   /* Loop forever, doing tests which should always succeed, with lots of signals */
   int x = 0;
   int i = 0;
   while (1) {
     x = i;
     int j = x;
     if (j != i)
       {
          printf("failed: %d isn't equal to %d, apparently\n", i, j);
          break;
       }
     i++;
  }
  return 0;
}

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple