1.7.14-2: pthread_cancel and pthread_kill not working as expected

2012-05-09 Thread Otto Meta
Greetings everyone,

while porting a project from Linux to Cygwin I noticed that pthread_cancel
was having trouble cancelling threads blocked on semaphores and reads
from stdin.

Another user had a similar problem a while ago:
http://sourceware.org/ml/cygwin/2011-01/msg00374.html

According to the follow-up this was fixed for network sockets, but
Windows seems to tread networks socket different from everything else
and the problem might not apply in my case.

The user also mentioned trying pthread_kill to "wake" blocked threads
so I tried that as well, but that resulted in completely different
threads in my program waking up.

My question is now whether I'm using pthread_cancel and pthread_kill
incorrectly or if there's some functionality missing in the certainly
not trivial Cygwin implementation of those functions.

A program to demonstrate the problems is attached. It contains six
different tests that behave slightly different depending on which
function the "simplethread" function blocks on.

You can find the expected and actual results that I got for the six
tests at the bottom of this mail. The expected results correspond to
what the readily available man-pages for pthread_cancel and pthread_kill
state and I verified the tests on a Linux system.

tl;dr version of the results:
- Using pthread_cancel on a blocked thread with deferred cancel blocks
  the calling thread.
- Threads blocked on semaphores, reads from stdin or pause() aren't
  cancelled.
- Signals seem to wake the wrong threads in some cases.

I have no explanation for this, so any ideas and suggestions are welcome.

Cheers,
Otto


Test 1:
  Leave threads at deferred cancel and cancel each thread.
Expected result:
  All threads are cancelled.
Actual result:
  Blocking on semapthore: Main thread hangs on first call to pthread_cancel().
  Blocking on pause(): Same as semaphore.
  Blocking on read(): Not deterministic: Main thread hangs on random call
to pthread_cancel().

Test 2:
  Set cancel type to asynchronous and cancel each thread.
Expected result:
  All threads are cancelled.
Actual result:
  Independent of what the threads are blocked on, nothing is cancelled.

Test 3:
  Send SIGUSR1 once to each thread.
Expected result:
  Each thread executes the signal handler once.
Actual result:
  Blocking on semaphore:
Poking thread 2 (0x80020410)
Thread 0 encountered an error: Interrupted system call (0x80010298)
Poking thread 1 (0x80020370)
Thread 1 executes signal handler (0x80020370)
Thread 1 encountered an error: Interrupted system call (0x80020370)
Poking thread 0 (0x80010298)
Thread 2 executes signal handler (0x80020410)
Thread 2 encountered an error: Interrupted system call (0x80020410)
Woken threads don't correspond to signalled threads, not all of them
execute the signal handler.
  Blocking on pause(): Same as semaphore.
  Blocking on read(): One thread executes the signal handler, the other
two don't. Thread chosen seemingly at random. This could be a
side-effect of all threads reading from stdin, but I still seems
broken.

Test 4:
  Send SIGUSR1 to one thread repeatedly (doesn't exit by design).
Expected result:
  The target thread executes the signal handler each time.
Actual result:
  Blocking on semaphore: Independent of the targeted thread, thread 0
wakes up once and executes the signal handler if thread 0 was
signalled. No thread cares about further signals.
  Blocking on pause(): Same as semaphore.
  Blocking on read(): Not deterministic: Targeted thread either executes
the signal handler every time or not at all.

Test 5:
  Cancel each thread asynchronously and poke them with SIGUSR1 afterwards.
Expected result:
  If a targeted thread isn't cancelled by pthread_cancel(), the signal
  should wake it up so that the cancel event can be handled.
Actual result:
  Blocking on semaphore:
Killing thread 2 (0x80020410)
Poking thread 2 (0x80020410)
Thread 0 encountered an error: Interrupted system call (0x80010298)
Killing thread 1 (0x80020370)
Poking thread 1 (0x80020370)
Thread 2 exiting (0x80020410)
Killing thread 0 (0x80010298)
Poking thread 0 (0x80010298)
Thread 1 exiting (0x80020370)
Responding threads don't correspond to signalled threads, wrong
threads exit if they have been cancelled already.
  Blocking on pause(): Same as semaphore.
  Blocking on read(): Not deterministic: One thread exits when poked,
the other two stay.

Test 6:
  Cancel each thread asynchronously and poke them with SIGUSR1 until they
  die.
Expected result:
  If a targeted thread isn't cancelled by pthread_cancel(), the signal
  should wake it up so that the cancel event can be handled. If the first
  signal "misses", one of the following should hit.
Actual result:
  Blocking on semaphore:
Killing and poking thread 2 will result in one response to the signal
from thread 0, then nothing.
Killing and poking thread 1 will result in one res

Re: Cygwin passes through null writes to other software when redirecting standard input/output (i.e. piping)

2012-05-10 Thread Otto Meta
Hi James,

> 1.  Cygwin would need an additional function with a parameter to specify
> byte pipes (maybe you already added this, I have not checked the recent
> source code very much).

You just missed the announcement:

On 2012-05-10 08:28, Corinna Vinschen wrote:
[snip]
> I just released 1.7.15.  This is a bugfix release.  Only one new feature
> has been added.
[snip]
> - Add CYGWIN=pipe_byte option to force opening of pipes in byte mode
>   rather than message mode.

That's probably just for you.

Cheers,
Otto

--
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



Re: Cygwin Commands

2012-05-17 Thread Otto Meta
> Here's what is going on...

Here’s your solution:
http://lmgtfy.com/?q=unix+for+beginners

> When I enter:
> 
> admin@mypc ~
> $cd
> 
> admin@mypc ~
> $

The first guide on the search mentioned above already has the answer for you.

> or
> 
> admin@mypc ~
> $dir
> 
> admin@mypc ~
> $

Pretty much any Unix beginners guide can help you. If not, we can't either.

> Could it be some system environment or special permission setting I may
> have overlooked?

Seems to be a PEBKAC setting.

Otto

--
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



Re: 1.7.15-1: pthread_cancel and pthread_kill not working as expected

2012-05-18 Thread Otto Meta
Greetings,

as I got no response to my first question, I tried two older Cygwin
versions to narrow down the problem. Maybe this’ll help someone to
figure out the cause.

I tried 1.7.9 and 1.7.12-1, with the results of 1.7.12-1 being exactly
like the ones from 1.7.14-2 and 1.7.15-1. Unfortunately I couldn’t dig
up any versions between 1.7.9 and 1.7.12-1.

Results from 1.7.12-1 (for semaphores, detailed results in my last mail):
Test 1: Main thread hangs on pthread_cancel() (PTHREAD_CANCEL_DEFERRED)
Test 2: Threads ignore pthread_cancel() (PTHREAD_CANCEL_ASYNCHRONOUS)
Test 3: Signals often wake the wrong thread
Test 4: Wrong thread wakes up once, then nothing
Test 5: Some threads exit, depending on whether the signal reached the
right thread
Test 6: Thread isn't cancelled even after a waking it with a signal

On 1.7.9 things are a bit different:
Test 1: PTHREAD_CANCEL_DEFERRED
semaphore/pause: All threads are cancelled via pthread_cancel()
read: No thread is cancelled
Test 2: PTHREAD_CANCEL_ASYNCHRONOUS
Threads ignore pthread_cancel()
Test 3: semaphore/read: No thread wakes up or executes the signal handler,
  sleep() doesn't sleep any more after the first signal (returns
  immediately)
pause: All threads wake up on every signal, correct thread
  executes signal handler
Test 4: semaphore/read: No thread wakes up or executes the signal handler,
  sleep() doesn't sleep any more after the first signal (returns
  immediately)
pause: All threads wake up on every signal, correct thread
  executes signal handler
Test 5: semaphore: No thread is killed, sleep() doesn't sleep any more
pause: First thread cancelled, other threads won't pause()
  any more and run amok
read: Some threads are killed, sleep() doesn't sleep any more
Test 6: semaphore/pause: No thread is killed, sleep() doesn't sleep
  any more
pause: First thread cancelled, other threads won't pause()
  any more and run amok

Sorry if I’m mixing two (or three?) problems, but they all seem
pthreads-related.

pthread_cancel deferred:
Worked on threads blocked in sem_wait() and pause() in 1.7.9, doesn’t work
any more in 1.7.12-1 and newer and instead hangs calling thread. I’d
consider this one a regression. Didn’t work on threads blocked in read()
in any tested version.

pthread_cancel asynchronous:
No thread is cancelled in any tested version. Calling thread doesn’t hang,
though.

pthread_kill:
In 1.7.9 a signal to any thread wakes up all threads blocked in pause()
and the correct thread executes the signal handler. Doesn’t wake threads
blocked in sem_wait() or read(). After delivering a signal, pause() and
sleep() don’t block any more and return immediately.
In 1.7.12-1 and newer sleep() and pause() won’t break and not all threads
are woken up. Instead only one thread is woken, but unfortunately not
always the correct one.

While signal handling mostly seems to have improved, cancelling
got worse. Especially the fact that the calling thread blocks in
pthread_cancel can be quite a show-stopper.

Any suggestions or ideas?

Cheers,
Otto

--
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



Re: 1.7.15-1: pthread_cancel and pthread_kill not working as expected

2012-05-21 Thread Otto Meta
> You should always try the most recent http://cygwin.com/snapshots.

Thanks for the suggestion, that did indeed change something: The tests
yield the same half-broken behaviour for pthread_cancel as with 1.7.7
and 1.7.9. That’s better than the almost completely broken behaviour
from 1.7.12-1 to 1.7.15-1. pthread_kill is still as unreliable as in
1.7.12-1 and newer, though.

Results with cygwin1-20120517.dll:

Test 1:
  Blocking on semaphore: Works
  Blocking on pause(): Works
  Blocking on read(): Not deterministic: One thread is killed, the other
two stay

Test 2:
  Independent of what the threads are blocked on, nothing is cancelled.

Test 3:
  Blocking on semaphore: May or may not signal the correct thread.
  Blocking on pause(): Same as semaphore.
  Blocking on read(): One thread executes the signal handler, the other
two don't. Thread chosen seemingly at random.

Test 4:
  Not deterministic: Targeted thread either executes the signal handler
  every time or not at all.

Test 5:
  Not deterministic: Threads may or may not exit after being poked.

Test 6:
  Not deterministic: Threads may or may not exit after being poked.

In short:
- Deferred pthread_cancel seems to work.
- Asynchronous pthtread_cancel seems to have no effect.
- pthread_kill is basically hit or miss.

Otto

--
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



Re: 1.7.15-1: pthread_cancel and pthread_kill not working as expected

2012-05-21 Thread Otto Meta
> Would you mind to provide *simple* testcases to allow easy debugging
> of your observations?

I reduced the various tests to three rather simple individual testcases
because those show possibly different bugs.

Testcase cancel deferred:
Works with 1.7.9 and 20120517 snapshot, fails (hangs) with 1.7.12-1
and 1.7.15-1.

Testcase cancel asynchronous:
Async cancel seems to have no effect with any tested version.

Testcase signal/kill:
Signals may or may not reach the correct thread with 1.7.12-1 and newer.

Otto
#include 
#include 
#include 
#include 
#include 
#include 
#include 

pthread_t tids[3];
sem_t semaphore;

static void cleanup_handler(void *arg) {
  int *intptr = (int*)arg;
  pthread_t self = pthread_self();
  fprintf(stderr, "Thread %i exiting (%p)\n", *intptr, self);
}

static void* simplethread(void *arg) {
  int *intptr = (int*)arg;
  pthread_t self = pthread_self();
  fprintf(stderr, "Thread %i starting (%p)\n", *intptr, self);

  pthread_cleanup_push(&cleanup_handler, intptr);

  while (1) {
if (sem_wait(&semaphore) != 0) {
  fprintf(stderr, "Thread %i encountered an error: %s (%p)\n",
  *intptr, strerror(errno), self);
} else {
  fprintf(stderr, "Thread %i woke up just fine\n", *intptr);
}
  }

  pthread_cleanup_pop(1);
  return NULL;
}

int main() {
  fprintf(stderr, "Testing deferred pthread_cancel()\n\n");

  int i;
  int result;

  sem_init(&semaphore, 0, 0);

  for (i=0; i<3; i++) {
int *intptr = (int*)malloc(sizeof(int));
*intptr = i;
result = pthread_create(tids+i, NULL, &simplethread, intptr);
if (result != 0) {
  fprintf(stderr, "Can't create thread: %s\n", strerror(result));
  return 1;
}
  }

  sleep(1);
  fprintf(stderr, "\n");

  int mainint = 42;
  pthread_cleanup_push(&cleanup_handler, &mainint);

  for (i=2; i>=0; i--) {
fprintf(stderr, "Cancelling thread %i (%p)\n", i, tids[i]);
result = pthread_cancel(tids[i]);
if (result != 0) {
  fprintf(stderr, "Error during pthread_cancel: %s\n", strerror(result));
}
sleep(1);
  }

  fprintf(stderr, "\n");
  for (i=0; i<3; i++) {
result = pthread_kill(tids[i], 0);
if (result == 0) {
  fprintf(stderr, "Thread %i is still there (%p)\n", i, tids[i]);
} else {
  fprintf(stderr, "Thread %i is gone (%p)\n", i, tids[i]);
}
  }

  pthread_cleanup_pop(0);
  return 0;
}
#include 
#include 
#include 
#include 
#include 
#include 
#include 

pthread_t tids[3];
sem_t semaphore;

static void cleanup_handler(void *arg) {
  int *intptr = (int*)arg;
  pthread_t self = pthread_self();
  fprintf(stderr, "Thread %i exiting (%p)\n", *intptr, self);
}

static void* simplethread(void *arg) {
  int *intptr = (int*)arg;
  pthread_t self = pthread_self();
  fprintf(stderr, "Thread %i starting (%p)\n", *intptr, self);

  pthread_cleanup_push(&cleanup_handler, intptr);

  int oldtype;
  pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, &oldtype);
  fprintf(stderr, "Changing canceltype from %i to %i\n", oldtype, PTHREAD_CANCEL_ASYNCHRONOUS);

  while (1) {
if (sem_wait(&semaphore) != 0) {
  fprintf(stderr, "Thread %i encountered an error: %s (%p)\n",
  *intptr, strerror(errno), self);
} else {
  fprintf(stderr, "Thread %i woke up just fine\n", *intptr);
}
  }

  pthread_cleanup_pop(1);
  return NULL;
}

int main() {
  fprintf(stderr, "Testing asynchronous pthread_cancel()\n\n");

  int i;
  int result;

  sem_init(&semaphore, 0, 0);

  for (i=0; i<3; i++) {
int *intptr = (int*)malloc(sizeof(int));
*intptr = i;
result = pthread_create(tids+i, NULL, &simplethread, intptr);
if (result != 0) {
  fprintf(stderr, "Can't create thread: %s\n", strerror(result));
  return 1;
}
  }

  sleep(1);
  fprintf(stderr, "\n");

  int mainint = 42;
  pthread_cleanup_push(&cleanup_handler, &mainint);

  for (i=2; i>=0; i--) {
fprintf(stderr, "Cancelling thread %i (%p)\n", i, tids[i]);
result = pthread_cancel(tids[i]);
if (result != 0) {
  fprintf(stderr, "Error during pthread_cancel: %s\n", strerror(result));
}
sleep(1);
  }

  fprintf(stderr, "\n");
  for (i=0; i<3; i++) {
result = pthread_kill(tids[i], 0);
if (result == 0) {
  fprintf(stderr, "Thread %i is still there (%p)\n", i, tids[i]);
} else {
  fprintf(stderr, "Thread %i is gone (%p)\n", i, tids[i]);
}
  }

  pthread_cleanup_pop(0);
  return 0;
}
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

pthread_t tids[3];
sem_t semaphore;

static void cleanup_handler(void *arg) {
  int *intptr = (int*)arg;
  pthread_t self = pthread_self();
  fprintf(stderr, "Thread %i exiting (%p)\n", *intptr, self);
}

static void* simplethread(void *arg) {
  int *intptr = (int*)arg;
  pthread_t self = pthread_self();
  fprintf(stderr, "Thread %i starting (%p)\n", *intptr, self);

  pthread_cleanup_push(&cleanup_handler, intptr);

  while (1) {
if (sem_wait(&semaphore) != 0) {
  fprintf(stderr, "Thread %i

Re: 1.7.15-1: pthread_cancel and pthread_kill not working as expected

2012-05-22 Thread Otto Meta
>> Testcase cancel deferred:
>> Works with 1.7.9 and 20120517 snapshot, fails (hangs) with 1.7.12-1
>> and 1.7.15-1.
> If that works in the snapshot anyway, I'm not going to look into that
> one.

It worked in the reduced testcase with sem_wait(). With read() it’s
still half-broken. See below.

>> Testcase cancel asynchronous:
>> Async cancel seems to have no effect with any tested version.
> I think I found a solution for this problem.  See the comment in the
> patch at
> http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.cc.diff?cvsroot=src&r1=1.258&r2=1.259
> Please test the today's developer snapshot.

Asynchronous cancel seems to work as well as deferred cancel now. Thanks.

Both cancel types work with sem_wait() and pause() now, but for threads
blocked in read() they’re still unreliable. Only one of three blocked
threads is killed in the attached updated testcases.

>> Testcase signal/kill:
>> Signals may or may not reach the correct thread with 1.7.12-1 and newer.
> Confirmed. [...] This is cgf's domain so I leave it at that for now.

Okay, I’ll hope for him to respond then.

Otto
#include 
#include 
#include 
#include 
#include 
#include 

pthread_t tids[3];

static void cleanup_handler(void *arg) {
  int *intptr = (int*)arg;
  pthread_t self = pthread_self();
  fprintf(stderr, "Thread %i exiting (%p)\n", *intptr, self);
}

static void* simplethread(void *arg) {
  int *intptr = (int*)arg;
  pthread_t self = pthread_self();
  fprintf(stderr, "Thread %i starting (%p)\n", *intptr, self);
  char buffer[1] __attribute((unused));

  pthread_cleanup_push(&cleanup_handler, intptr);

  int oldtype;
  pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, &oldtype);
  fprintf(stderr, "Changing canceltype from %i to %i\n", oldtype, PTHREAD_CANCEL_ASYNCHRONOUS);

  while (1) {
if (read(STDIN_FILENO, buffer, 1) <= 0) {
  fprintf(stderr, "Thread %i encountered an error: %s (%p)\n",
  *intptr, strerror(errno), self);
} else {
  fprintf(stderr, "Thread %i woke up just fine\n", *intptr);
}
  }

  pthread_cleanup_pop(1);
  return NULL;
}

int main() {
  fprintf(stderr, "Testing asynchronous pthread_cancel()\n\n");

  int i;
  int result;

  for (i=0; i<3; i++) {
int *intptr = (int*)malloc(sizeof(int));
*intptr = i;
result = pthread_create(tids+i, NULL, &simplethread, intptr);
if (result != 0) {
  fprintf(stderr, "Can't create thread: %s\n", strerror(result));
  return 1;
}
  }

  sleep(1);
  fprintf(stderr, "\n");

  int mainint = 42;
  pthread_cleanup_push(&cleanup_handler, &mainint);

  for (i=2; i>=0; i--) {
fprintf(stderr, "Cancelling thread %i (%p)\n", i, tids[i]);
result = pthread_cancel(tids[i]);
if (result != 0) {
  fprintf(stderr, "Error during pthread_cancel: %s\n", strerror(result));
}
sleep(1);
  }

  fprintf(stderr, "\n");
  for (i=0; i<3; i++) {
result = pthread_kill(tids[i], 0);
if (result == 0) {
  fprintf(stderr, "Thread %i is still there (%p)\n", i, tids[i]);
} else {
  fprintf(stderr, "Thread %i is gone (%p)\n", i, tids[i]);
}
  }

  pthread_cleanup_pop(0);
  return 0;
}
#include 
#include 
#include 
#include 
#include 
#include 

pthread_t tids[3];

static void cleanup_handler(void *arg) {
  int *intptr = (int*)arg;
  pthread_t self = pthread_self();
  fprintf(stderr, "Thread %i exiting (%p)\n", *intptr, self);
}

static void* simplethread(void *arg) {
  int *intptr = (int*)arg;
  pthread_t self = pthread_self();
  fprintf(stderr, "Thread %i starting (%p)\n", *intptr, self);
  char buffer[1] __attribute((unused));

  pthread_cleanup_push(&cleanup_handler, intptr);

  while (1) {
if (read(STDIN_FILENO, buffer, 1) <= 0) {
  fprintf(stderr, "Thread %i encountered an error: %s (%p)\n",
  *intptr, strerror(errno), self);
} else {
  fprintf(stderr, "Thread %i woke up just fine\n", *intptr);
}
  }

  pthread_cleanup_pop(1);
  return NULL;
}

int main() {
  fprintf(stderr, "Testing deferred pthread_cancel()\n\n");

  int i;
  int result;

  for (i=0; i<3; i++) {
int *intptr = (int*)malloc(sizeof(int));
*intptr = i;
result = pthread_create(tids+i, NULL, &simplethread, intptr);
if (result != 0) {
  fprintf(stderr, "Can't create thread: %s\n", strerror(result));
  return 1;
}
  }

  sleep(1);
  fprintf(stderr, "\n");

  int mainint = 42;
  pthread_cleanup_push(&cleanup_handler, &mainint);

  for (i=2; i>=0; i--) {
fprintf(stderr, "Cancelling thread %i (%p)\n", i, tids[i]);
result = pthread_cancel(tids[i]);
if (result != 0) {
  fprintf(stderr, "Error during pthread_cancel: %s\n", strerror(result));
}
sleep(1);
  }

  fprintf(stderr, "\n");
  for (i=0; i<3; i++) {
result = pthread_kill(tids[i], 0);
if (result == 0) {
  fprintf(stderr, "Thread %i is still there (%p)\n", i, tids[i]);
} else {
  fprintf(stderr, "Thread %i is gone (%p)\n", i, tids[i]);
}
  }

  pthread_cleanup_pop(0);
  return 0;
}

Re: 1.7.15-1: pthread_cancel and pthread_kill not working as expected

2012-05-24 Thread Otto Meta
> I think I found the problem.  I've uploaded a new snapshot.  Please give
> it a try.

My testcases for asynchronous and deferred cancel work on threads
blocked in sem_wait() but still fail mostly on threads blocked in
read(STDIN_FILENO, ...), same as before. Sorry about that.

$ uname -v
20120523 21:51:34

Fresh output of cygcheck -s -v -r attached, if that helps.

Otto

Cygwin Configuration Diagnostics
Current System Time: Thu May 24 10:47:11 2012

Windows 7 Enterprise Ver 6.1 Build 7601 Service Pack 1

Running under WOW64 on AMD64

Path:   D:\Software\cygwin\usr\local\bin
D:\Software\cygwin\bin
C:\Program Files (x86)\Atmel\AVR Tools\AVR32 Toolchain\bin
C:\WinAVR-20100110\bin
C:\WinAVR-20100110\utils\bin
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0
C:\Program Files (x86)\Common Files\Roxio Shared\DLLShared
C:\Program Files (x86)\Common Files\Roxio Shared\9.0\DLLShared
C:\Program Files\MATLAB\R2008a\bin
C:\Program Files\MATLAB\R2008a\bin\win64
C:\Program Files (x86)\Microsoft SQL Server\90\Tools\binn
C:\Program Files (x86)\IVI Foundation\IVI\bin
C:\Program Files\IVI Foundation\IVI\bin
C:\Program Files (x86)\IVI Foundation\VISA\winnt\agvisa
C:\Program Files (x86)\IVI Foundation\VISA\winnt\bin
C:\Program Files (x86)\NASM
C:\Program Files (x86)\Atmel\Flip 3.4.1\bin
D:\Software\Python3.2

Output from D:\Software\cygwin\bin\id.exe
UID: 1000(MBA) GID: 513(None)
=513(None) 545(Benutzer)  1005(Debuggerbenutzer)

SysDir: C:\Windows\system32
WinDir: C:\Windows

USER = 'MBA'
PWD = '/tmp'
HOME = '/home/MBA'

HOMEPATH = '\Users\MBA'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man:'
APPDATA = 'C:\Users\MBA\AppData\Roaming'
ProgramW6432 = 'C:\Program Files'
HOSTNAME = 'TempleOfTheDog'
SHELL = '/bin/bash'
TERM = 'cygwin'
RoxioCentral = 'C:\Program Files (x86)\Common Files\Roxio Shared\9.0\Roxio 
Central33\'
PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 23 Stepping 10, GenuineIntel'
WINDIR = 'C:\Windows'
VXIPNPPATH64 = 'C:\Program Files\IVI Foundation\VISA\'
PUBLIC = 'C:\Users\Public'
OLDPWD = '/tmp'
USERDOMAIN = 'TEMPLEOFTHEDOG'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\ProgramData'
!:: = '::\'
temp = 'C:\Users\MBA\AppData\Local\Temp'
VS90COMNTOOLS = 'C:\Program Files (x86)\Microsoft Visual Studio 
9.0\Common7\Tools\'
COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files'
tmp = 'C:\Users\MBA\AppData\Local\Temp'
VXIPNPPATH = 'C:\Program Files (x86)\IVI Foundation\VISA\'
USERNAME = 'MBA'
PROCESSOR_LEVEL = '6'
ProgramFiles(x86) = 'C:\Program Files (x86)'
PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\'
IVIROOTDIR32 = 'C:\Program Files (x86)\IVI Foundation\IVI\'
FP_NO_HOST_CHECK = 'NO'
CARBON_MEM_DISABLE = '1'
SYSTEMDRIVE = 'C:'
PROCESSOR_ARCHITEW6432 = 'AMD64'
LANG = 'de_DE.UTF-8'
USERPROFILE = 'C:\Users\MBA'
TZ = 'Europe/Berlin'
PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = '\\TEMPLEOFTHEDOG'
CommonProgramW6432 = 'C:\Program Files\Common Files'
PROCESSOR_ARCHITECTURE = 'x86'
LOCALAPPDATA = 'C:\Users\MBA\AppData\Local'
HISTCONTROL = 'ignoredups'
ProgramData = 'C:\ProgramData'
SHLVL = '1'
IVIROOTDIR64 = 'C:\Program Files\IVI Foundation\IVI\'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
HOMEDRIVE = 'C:'
!D: = 'D:\Software\cygwin\bin'
PROMPT = '$P$G'
COMSPEC = 'C:\Windows\system32\cmd.exe'
SYSTEMROOT = 'C:\Windows'
PRINTER = 'KONICA MINOLTA Universal PS'
PROCESSOR_REVISION = '170a'
UGII_3DCONNEXION_LIBRARY = '%UGII_BASE_DIR%\ugalliance\vendor\startup\3DxNX.dll'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = 'C:\Program Files (x86)'
NUMBER_OF_PROCESSORS = '2'
AVR32_HOME = 'C:\Program Files (x86)\Atmel\AVR Tools\AVR32 Toolchain'
SESSIONNAME = 'Console'
COMPUTERNAME = 'TEMPLEOFTHEDOG'
_ = '/usr/bin/cygcheck'

HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygwin
HKEY_CURRENT_USER\Software\Cygwin\Installations
  (default) = '\??\D:\Software\cygwin'
HKEY_CURRENT_USER\Software\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygwin\setup
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations
  (default) = '\??\D:\Software\cygwin'
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup
  (default) = 'D:\Software\cygwin'

obcaseinsensitive set to 1

Cygwin installations found in the registry:
  System: Key: d1d85fb7bc451065 Path: D:\Software\cygwin
  User:   Key: d1d85fb7bc451065 Path: D:\Software\cygwi

Re: 1.7.15-1: pthread_cancel and pthread_kill not working as expected

2012-05-24 Thread Otto Meta
> My testcases for asynchronous and deferred cancel work on threads
> blocked in sem_wait() but still fail mostly on threads blocked in
> read(STDIN_FILENO, ...), same as before. Sorry about that.

I spoke too soon. There seems to be some kind of runtime decay and a
dependency on semaphore.h.

Running the same test or the two tests alternating works for about three
times just as expected but further runs fail as before. A reboot fixes
that and gives me another few chances. This only applies to read().
sem_wait() always works.

If the test code includes semaphore.h but doesn’t even use any of its
functions it fails right away, just like before. A reboot doesn’t help.

It’s getting weirder by the day...

Otto

--
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



Re: 1.7.15-1: pthread_cancel and pthread_kill not working as expected

2012-05-24 Thread Otto Meta
On 2012-05-24 13:19, Corinna Vinschen wrote:
> You know that Cygwin is just a user space DLL, right?  There's no state
> information kept in the OS beyond the lifetime of any process using the
> Cygwin DLL.  In case of pthreads, there's no state at all shared with
> other processes.

Yes, that’s exactly why I’m confused about it.

> But even if so, if you stop *all* Cygwin processes and then start
> another one, all info from the old processes is gone and you should be
> back to normal.  If that's not the case, I would suspect a case of BLODA.

Yes, I tried that and it changed nothing. I took the chance to uninstall
some unused software and stopped all dodgy-sounding Windows services,
including Windows Defender, so that the only thing left from the BLODA
was the nVidia driver: No change.

Rebasing also didn’t help.

>> If the test code includes semaphore.h but doesn’t even use any of its
>> functions it fails right away, just like before. A reboot doesn’t help.
> Is that with the same "read" testcases you sent two days ago?  If so, I
> can't reproduce it.  I ran both tests in a loop, with and without an
> additional semaphore.h, but to no avail.  They both just work.

Yes, same tests (the ones blocking on read()), but the semaphore.h was
probably unrelated after all.

I also ran the tests continuously and discovered the following:

Running the same test several times manually from a cmd shell works a
few times, then fails. Running the async and deferred tests alternating
from cmd works, even after they failed previously.

Running one of the tests manually from bash fails most of the time.

$ while :; do ./testcase_cancel_asynchronous; done
First test run usually fails, further runs succeed. Same for the
deferred testcase.

$ sleep 1; while :; do ./testcase_cancel_asynchronous; done
All test runs succeed, including the first one. Same for the deferred
testcase.

I am now convinced that my system is toying with me.

As I actually don’t need to read from stdin with several threads and
only discovered this problem while you fixed async cancel (thanks for
that), I’m inclined to ignore this “problem” and stop wasting your
time, unless you want me to try something else to debug this.

> This is under W7 on a dual-core machine.

Same here.

Otto

--
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



Re: 1.7.15-1: pthread_cancel and pthread_kill not working as expected

2012-05-24 Thread Otto Meta
> Weird.  I tried under CMD now as well, but it still runs and runs and
> runs, without a failure.  Tested on XP, W7, and 2008 R2.

Maybe It’s Just Me then.

> Another idea is that your system also fails due to the problem reported
> in http://cygwin.com/ml/cygwin/2012-05/msg00522.html
> I'm just about to generate another snapshot.  You could see if that
> helps for some reason.  I doubt it, but still...

No change.

$ sleep 0.001; ./testcase_cancel_asynchronous
Fails.

$ sleep 0.1; ./testcase_cancel_asynchronous
Succeeds.

:-?

Otto

--
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



sem_wait frequently returning with EINTR [Was: Re: How to "bisect" Cygwin?]

2012-06-01 Thread Otto Meta
> The basic issue is that sem_wait() is being kicked out with EINTR
> extremely frequently (9 out of 10 times or more), which slows my code
> to a crawl as it repeatedly retries sem_wait() until it finally
> returns zero.  In 1.7.9, it does not appear that sem_wait() is
> preempted in this fashion; the thread would simply wait on the
> semaphore until it was sem_post()'d and then continue as expected.

Are you using signals or functions that use signals internally? Signals are
a bit wonky in 1.7.9 and they seem to be pretty much broken in 1.7.12 and
newer (I didn’t try any snapshots). Have a look at the problem I reported:
http://cygwin.com/ml/cygwin/2012-05/msg00186.html
While the cancelling part seems to be mostly fixed by now, the signal part
is still unchanged.

Maybe you could try test 3 from my test program attached to the above
mentioned post. If its output changes along with your program’s behaviour
when you try different Cygwin versions, your problem could be signal-related.

Warren Young wrote in http://cygwin.com/ml/cygwin/2012-06/msg00032.html:
> You should just get an infinite series of "Child timed out normally waiting
> for the semaphore." messages from it after initialization, one per second.

This works for me out of the box, but if I create one or more pthreads before
the alarm loop it just fails: Some other thread gets woken up and the main
thread stays stuck in sem_wait.

If Ryan had told us more about his program, we’d know whether he uses multiple
threads or multiple processes...

Cheers,
Otto

--
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



Re: s?wprintf family of functions has broken %s formatter output

2012-06-11 Thread Otto Meta
> `-->  ./testvswprintf.exe

> this works, 1, 2, 3...
> but the following does not:
> ret: 1
> buf: >T<
>> T<
> ret: 4
> wcout: >THIS IS A TEST<
> 
> The same code works well on both Ubuntu with GCC and on Windows with
> Visual Studio 2010.


I just tried your test with g++ (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2:

$> ./testvswprintf
this works, 1, 2, 3...
but the following does not:
ret: 1
buf: >T<
>T<
ret: 4
wcout: >THIS IS A TEST<

Looks quite the same, so it’s not really a Cygwin-only problem.
My Ubuntu 11.04 is a bit dated already, so maybe you have a newer
Ubuntu version with a fixed swprintf?

Otto

--
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



Re: s?wprintf family of functions has broken %s formatter output

2012-06-11 Thread Otto Meta
> I have done some more checking and I might have been wrong about the

> Ubuntu and Linux in general. It looks like the formatting strings are
> incompatible between MSVC and *NIX. It appears that either %S (SUSv2)
> or %ls (C99) is needed on *NIX. MSVC switches the meaning of %s for
> wprintf() (http://linux.die.net/man/3/printf).


Changing %s in your test program to %ls works for me on Ubuntu.
Have you tried %ls in MSVC? That should work as well, according to
http://msdn.microsoft.com/de-de/library/tcxf1dw6%28v=vs.80%29.aspx

Otto

--
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



Re: Trusted Software Vendor

2012-06-11 Thread Otto Meta
> This is because of the file being downloaded from the web (check file streams

> for details).
> You can easily cleanup the file metadata by copying it to FAT drive (Flash
> disk/memory card).


The file stream with the "downloaded from the web" information can
easily be removed with the Stream tool without any copying:
http://technet.microsoft.com/en-us/sysinternals/bb897440.aspx

You can probably make a simple context menu entry as well.

Otto

--
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



Re: Trusted Software Vendor

2012-06-11 Thread Otto Meta
> Out of curiosity would downloading setup.exe using wget also work

> around the problem?


Most likely. I don't think wget cares about protecting Windows users
from their own stupidity. If you use wget, you should know what you're
doing.

How about you just give it a try?

Otto

--
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



Re: RCS file corruption.

2012-06-20 Thread Otto Meta
> I have experienced this problem several times.  In my case it seemed

> to be a problem between 'Unix' and 'DOS' files.  In each case, I have
> been able to fix it by editing the RCS file using vim and deleting all
> the extraneous carriage returns - :%s/^M$//  Sometimes I've had
> to do it twice.  Once I do that, it seems to work.


fromdos or dos2unix might save you a lot of work there. ;-)

Otto

--
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



Re: 1.7.15-1: pthread_cancel and pthread_kill not working as expected

2012-07-11 Thread Otto Meta
On 2012-05-22 13:02, Corinna Vinschen wrote:
[...]
>> Testcase signal/kill:
>> Signals may or may not reach the correct thread with 1.7.12-1 and newer.
> 
> Confirmed.  I think the reason is that we only have a single event to
> signal that a POSIX signal arrived instead of a per-thread event, but
> I'm not sure.  This is cgf's domain so I leave it at that for now.

Is this problem still in the queue? The newest snapshot yields the
same results as before.

$ uname -srv
CYGWIN_NT-6.1-WOW64 1.7.16s(0.261/5/3) 20120708 00:52:15

I attached a slightly simpler version of the testcase.

Test output:

  Sending SIGUSR1 to thread 2
  Thread 0 encountered an error: Interrupted system call

  Sending SIGUSR1 to thread 1
  Thread 1 executes signal handler
  Thread 1 encountered an error: Interrupted system call

  Sending SIGUSR1 to thread 0
  Thread 2 executes signal handler
  Thread 2 encountered an error: Interrupted system call

Otto
#include 
#include 
#include 
#include 
#include 
#include 
#include 

pthread_t tids[3];

static void* simplethread(void *arg) {
  int *intptr = (int*)arg;
  pthread_t self = pthread_self();
  fprintf(stderr, "Thread %i starting (%p)\n", *intptr, self);

  while (1) {
if (pause() != 0) {
  fprintf(stderr, "Thread %i encountered an error: %s (%p)\n",
  *intptr, strerror(errno), self);
} else {
  fprintf(stderr, "Thread %i woke up just fine\n", *intptr);
}
  }

  return NULL;
}

static void sigusr1_handler(int signal __attribute((unused))) {
  pthread_t self = pthread_self();

  // Search for thread number
  int tnum = 0;
  while (tnum < 3) {
if (tids[tnum] == self) {
  break;
}
tnum++;
  }

  fprintf(stderr, "Thread %i executes signal handler (%p)\n", tnum, self);
}

static void install_handler(void) {
  struct sigaction act;
  act.sa_handler = &sigusr1_handler;
  sigemptyset(&(act.sa_mask));
  act.sa_flags = 0;

  // Install signal handler
  if (sigaction(SIGUSR1, &act, NULL) != 0) {
fprintf(stderr, "Can't set signal handler: %s\n", strerror(errno));
exit(1);
  }

  // Make sure SIGUSR1 is not blocked
  sigset_t sset;
  sigemptyset(&sset);
  sigaddset(&sset, SIGUSR1);
  if (sigprocmask(SIG_UNBLOCK, &sset, NULL) != 0) {
fprintf(stderr, "Can't unblock SIGUSR1: %s\n", strerror(errno));
  }
}

int main() {
  fprintf(stderr, "Testing pthread_kill()\n\n");

  int i;
  int result;

  install_handler();

  // Create threads
  for (i=0; i<3; i++) {
int *intptr = (int*)malloc(sizeof(int));
*intptr = i;
result = pthread_create(tids+i, NULL, &simplethread, intptr);
if (result != 0) {
  fprintf(stderr, "Can't create thread: %s\n", strerror(result));
  return 1;
}
  }

  sleep(1);
  install_handler();
  fprintf(stderr, "\n");

  // Poke all threads
  for (i=2; i>=0; i--) {
fprintf(stderr, "Sending SIGUSR1 to thread %i (%p)\n", i, tids[i]);
result = pthread_kill(tids[i], SIGUSR1);
if (result != 0) {
  fprintf(stderr, "Error during pthread_kill: %s\n", strerror(result));
}
sleep(1);
fprintf(stderr, "\n");
  }

  return 0;
}

--
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

Re: tar won't extract all files when a file with exe extension precedes the same without extension inside the archive

2012-07-12 Thread Otto Meta
> 2.  Since this is a "Windows thing", is there some reason why the execution
> of "file" or "file.exe" isn't handled as a special case in the exec call
> (and all its flavors) and no place else?

make, for example? If you have a rule that creates "foo" from foo.c,
gcc will actually create "foo.exe". The next time you run make, it
won’t see "foo" and recreate "foo.exe", even if "foo.exe" is still
up to date.

With the special handling of .exe, when make checks for "foo", cygwin
checks "foo" first, doesn’t find anything, and then checks "foo.exe",
returning its result to make and make is happy.

Anothen example: A script tries to execute "foo" from . , cygwin
executes "foo.exe" instead and the script thinks "foo" exists,
but a subsequent "touch foo" (or "rm foo" or whatever) fails, which
is massively inconsistent.

I consider the current handling of .exe files quite consistent.

Or, in other words, when forced to choose between the two pains,
I’d rather endure this.

Otto

--
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