date:20180310

Re: [Mingw-w64-public] Deadlock in winpthreads' pthread_cond_signal()

2018-03-10 Thread Liu Hao

在 2018/3/10 20:46, Sitsofe Wheeler 写道:
> On 10 March 2018 at 12:38, Liu Hao  wrote:
>> 在 2018/3/10 20:06, Sitsofe Wheeler 写道:
>>> Reattaching example program with .txt extension and just in case you
>>> can also download it from http://sucs.org/~sits/test/signalhang.c .
>>>
>>
>> This seems not producible on my Windows 7, but it is indeed reproducible
>> on Wine 3.3 on Linux Mint 18.3. This renders the bug valid,
> 
> It definitely happened on 2012 R2 for me (the backtrace I gave was
> from running on 2012 R2) but I believe it was more intermittent than
> under Wine. I suggest raising thread_count to 100 and seeing if that
> makes it more reproducible on native Windows.

No, not reproducible at all, even with 1000 threads.

I created a ticket for it:
.

> 
>> I had a peek at 'cond.c' but was still unclear about what was going on.
>> Further investigation is required.
> 


-- 
Best regards,
LH_Mouse
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Deadlock in winpthreads' pthread_cond_signal()

2018-03-10 Thread Sitsofe Wheeler

On 10 March 2018 at 12:38, Liu Hao  wrote:
> 在 2018/3/10 20:06, Sitsofe Wheeler 写道:
>> Reattaching example program with .txt extension and just in case you
>> can also download it from http://sucs.org/~sits/test/signalhang.c .
>>
>
> This seems not producible on my Windows 7, but it is indeed reproducible
> on Wine 3.3 on Linux Mint 18.3. This renders the bug valid,

It definitely happened on 2012 R2 for me (the backtrace I gave was
from running on 2012 R2) but I believe it was more intermittent than
under Wine. I suggest raising thread_count to 100 and seeing if that
makes it more reproducible on native Windows.

> I had a peek at 'cond.c' but was still unclear about what was going on.
> Further investigation is required.

-- 
Sitsofe | http://sucs.org/~sits/

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Deadlock in winpthreads' pthread_cond_signal()

2018-03-10 Thread Sitsofe Wheeler

On 10 March 2018 at 10:37, Liu Hao  wrote:
> 在 2018/3/10 18:14, Sitsofe Wheeler 写道:
>> Hi,
>>
>> It's possible to trigger a deadlock in winpthreads'
>> pthread_cond_signal() when using the pthread_cond_signal() call
>> outside of a pthread_mutex_lock()/pthread_mutex_unlock() region. This
>> problem happens under Windows 2012 R2 with winpthreads-5.0.3
>> (Cygwin64) and winpthreads-7.2.0 (standalone) and also on Fedora 26
>> under wine-3.2-2.fc26.x86_64 using
>> mingw64-winpthreads-static-5.0.2-1.fc26.noarch. The problem was
>> originally seen by a Windows user of the fio project (see
>> https://www.spinics.net/lists/fio/msg06772.html ) but a standalone
>> program that reproduces the problem is attached. The problem is
>
> The attachment seemed swallowed by SourceForge. If it was a plaintext
> file, add a `.txt` extension and send it again.
>
> Thanks for your report.
>
>> intermittent (so you may need to up the threads/iterations or run the
>> program multiple times) but a backtrace of the thread with the hang
>> looks like this:

Reattaching example program with .txt extension and just in case you
can also download it from http://sucs.org/~sits/test/signalhang.c .

-- 
Sitsofe | http://sucs.org/~sits/
/* Program that demonstrates a hang in pthread_cond_signal when using
 * winpthreads. Compile with
 * x86_64-w64-mingw32-gcc -O3 -Wall -static -pthread signal_hang.c
 */

#include 
#include 
#include 
#include 
#include 
#include 

#define CHECK(x, msg) \
if (x != 0) { \
printf("%s failed\n", msg); \
goto err; \
}

enum {
MUTEX_LOCKED = 0,
MUTEX_UNLOCKED = 1
};

struct sh_mutex {
pthread_mutex_t lock;
pthread_cond_t cond;
int value;
int waiters;
uint64_t max_iterations;
uint64_t iteration;
};

struct sh_thread {
int id;
struct sh_mutex *mutex;
};

static void mutex_down(struct sh_mutex *mutex) {
pthread_mutex_lock(>lock);
while (mutex->value == MUTEX_LOCKED) {
mutex->waiters++;
pthread_cond_wait(>cond, >lock);
mutex->waiters--;
}
mutex->value = MUTEX_LOCKED;
pthread_mutex_unlock(>lock);
}

static void mutex_up(struct sh_mutex *mutex) {
int do_wake = 0;
uint64_t iteration;

pthread_mutex_lock(>lock);
if (mutex->value == MUTEX_LOCKED && mutex->waiters)
do_wake = mutex->waiters;
mutex->value = MUTEX_UNLOCKED;
iteration = mutex->iteration;
pthread_mutex_unlock(>lock);

if (do_wake) {
fprintf(stderr, "doing wake (waiters=%d, iteration=%" PRId64 
")...\n", do_wake, iteration);
pthread_cond_signal(>cond);
}
}

static void *contend_lock_thread(void *data) {
struct sh_thread *thread_data = (struct sh_thread*) data;
struct sh_mutex *mutex = thread_data->mutex;

while (1) {
uint64_t iteration;

mutex_down(mutex);
mutex->iteration++;
iteration = mutex->iteration;
usleep(5);
mutex_up(mutex);
if (iteration >= mutex->max_iterations)
break;
}

fprintf(stderr, "finishing thread %d\n", thread_data->id);
return NULL;
}

int main(void) {
struct sh_mutex mutex;
struct sh_thread *threads_data = NULL;
pthread_t *threads = NULL;
int thread_count;

CHECK(pthread_cond_init(, NULL), "pthread_cond_init");
CHECK(pthread_mutex_init(, NULL), "pthread_mutex_init");
mutex.value = MUTEX_UNLOCKED;
mutex.iteration = 0;
mutex.waiters = 0;

/* Change these to make the test longer */
thread_count = 50;
mutex.max_iterations = 1;

threads = malloc(sizeof(pthread_t) * thread_count);
threads_data = malloc(sizeof(struct sh_thread) * thread_count);
for (int i = 0; i < thread_count; i++) {
threads_data[i].id = i;
threads_data[i].mutex = 
CHECK(pthread_create([i], NULL, contend_lock_thread, 
_data[i]), "pthread_create");
}

for (int i = 0; i < thread_count; i++) {
CHECK(pthread_join(threads[i], NULL), "pthread_join");
}

if (threads)
free(threads);
if (threads_data)
free(threads_data);

printf("iterations done: %" PRId64 "\n", mutex.iteration);
return 0;
err:
perror("last error was");
return 1;
}
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net

Re: [Mingw-w64-public] Deadlock in winpthreads' pthread_cond_signal()

2018-03-10 Thread Liu Hao

在 2018/3/10 18:14, Sitsofe Wheeler 写道:
> Hi,
> 
> It's possible to trigger a deadlock in winpthreads'
> pthread_cond_signal() when using the pthread_cond_signal() call
> outside of a pthread_mutex_lock()/pthread_mutex_unlock() region. This
> problem happens under Windows 2012 R2 with winpthreads-5.0.3
> (Cygwin64) and winpthreads-7.2.0 (standalone) and also on Fedora 26
> under wine-3.2-2.fc26.x86_64 using
> mingw64-winpthreads-static-5.0.2-1.fc26.noarch. The problem was
> originally seen by a Windows user of the fio project (see
> https://www.spinics.net/lists/fio/msg06772.html ) but a standalone
> program that reproduces the problem is attached. The problem is

The attachment seemed swallowed by SourceForge. If it was a plaintext
file, add a `.txt` extension and send it again.

Thanks for your report.

> intermittent (so you may need to up the threads/iterations or run the
> program multiple times) but a backtrace of the thread with the hang
> looks like this:
> 


-- 
Best regards,
LH_Mouse
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC Fallthrough warnings.

2018-03-10 Thread jpmugaas



-Original Message-
From: Mateusz Mikuła  
Sent: Friday, March 9, 2018 7:41 PM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] GCC Fallthrough warnings.

There is no patch attached.

I hope this works:
===
diff --git a/mingw-w64-crt/stdio/mingw_pformat.c
b/mingw-w64-crt/stdio/mingw_pformat.c
index 350c6638..5ad3bb4c 100644
--- a/mingw-w64-crt/stdio/mingw_pformat.c
+++ b/mingw-w64-crt/stdio/mingw_pformat.c
@@ -2472,6 +2472,7 @@ __pformat (int flags, void *dest, int max, const
APICHAR *fmt, va_list argv)
 * and simply fall through.
 */
length = PFORMAT_LENGTH_LONG;
+/* fall through. */
 
  case 'c':
/*
@@ -2516,6 +2517,7 @@ __pformat (int flags, void *dest, int max, const
APICHAR *fmt, va_list argv)
 * and simply fall through.
 */
length = PFORMAT_LENGTH_LONG;
+/* fall through. */
 
  case 's':
if( (length == PFORMAT_LENGTH_LONG)
@@ -2679,6 +2681,7 @@ __pformat (int flags, void *dest, int max, const
APICHAR *fmt, va_list argv)
 * select lower case mode, and simply fall through...
 */
stream.flags |= PFORMAT_XCASE;
+/* fall through. */
 
  case 'E':
/*
@@ -2724,6 +2727,7 @@ __pformat (int flags, void *dest, int max, const
APICHAR *fmt, va_list argv)
 * simply fall through...
 */
stream.flags |= PFORMAT_XCASE;
+/* fall through. */
 
  case 'F':
/*
@@ -2767,6 +2771,7 @@ __pformat (int flags, void *dest, int max, const
APICHAR *fmt, va_list argv)
 * mode, and simply fall through...
 */
stream.flags |= PFORMAT_XCASE;
+/* fall through. */
 
  case 'G':
/*
@@ -2803,6 +2808,7 @@ __pformat (int flags, void *dest, int max, const
APICHAR *fmt, va_list argv)
  __pformat_gfloat( (long double)(va_arg( argv, double )),
 );
 
goto format_scan;
+/* fall through. */
 
  case 'a':
/*
@@ -2811,6 +2817,7 @@ __pformat (int flags, void *dest, int max, const
APICHAR *fmt, va_list argv)
 * fall through...
 */
stream.flags |= PFORMAT_XCASE;
+/* fall through. */
 
  case 'A':
/*
@@ -3168,6 +3175,7 @@ __pformat (int flags, void *dest, int max, const
APICHAR *fmt, va_list argv)
  stream.flags |= PFORMAT_ZEROFILL;
  break;
}
+/* fall through. */
 
  default:
/*
===


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Deadlock in winpthreads' pthread_cond_signal()

2018-03-10 Thread Sitsofe Wheeler

Hi,

It's possible to trigger a deadlock in winpthreads'
pthread_cond_signal() when using the pthread_cond_signal() call
outside of a pthread_mutex_lock()/pthread_mutex_unlock() region. This
problem happens under Windows 2012 R2 with winpthreads-5.0.3
(Cygwin64) and winpthreads-7.2.0 (standalone) and also on Fedora 26
under wine-3.2-2.fc26.x86_64 using
mingw64-winpthreads-static-5.0.2-1.fc26.noarch. The problem was
originally seen by a Windows user of the fio project (see
https://www.spinics.net/lists/fio/msg06772.html ) but a standalone
program that reproduces the problem is attached. The problem is
intermittent (so you may need to up the threads/iterations or run the
program multiple times) but a backtrace of the thread with the hang
looks like this:

(gdb) bt
#0  0x7ff9e03d079a in ntdll!ZwWaitForSingleObject ()
   from C:\windows\SYSTEM32\ntdll.dll
#1  0x7ff9dd801118 in WaitForSingleObjectEx ()
   from C:\windows\system32\KernelBase.dll
#2  0x0040346c in do_sema_b_wait_intern (sema=sema@entry=0x30,
nointerrupt=nointerrupt@entry=1, timeout=timeout@entry=4294967295)
at /usr/src/debug/mingw64-x86_64-winpthreads-5.0.3-1/src/cond.c:601
#3  0x004035ae in do_sema_b_wait (sema=0x30, nointerrupt=1,
timeout=4294967295, cs=0x6f98f0, val=0x6f9918)
at /usr/src/debug/mingw64-x86_64-winpthreads-5.0.3-1/src/cond.c:584
#4  0x0040383f in pthread_cond_signal (c=)
at /usr/src/debug/mingw64-x86_64-winpthreads-5.0.3-1/src/cond.c:327
#5  0x00401681 in mutex_up (mutex=0x23fde0) at signalhang.c:62
#6  contend_lock_thread (data=0x6f9bd0) at signalhang.c:77
#7  0x00405314 in pthread_create_wrapper (args=0x0)
at /usr/src/debug/mingw64-x86_64-winpthreads-5.0.3-1/src/thread.c:1492
#8  0x7ff9dfd60b13 in msvcrt!_strupr ()
   from C:\windows\system32\msvcrt.dll
#9  0x7ff9dfd60bcd in msvcrt!_endthreadex ()
   from C:\windows\system32\msvcrt.dll
#10 0x7ff9df6f13d2 in KERNEL32!BaseThreadInitThunk ()
   from C:\windows\system32\kernel32.dll
#11 0x7ff9e03554f4 in ntdll!RtlUserThreadStart ()
   from C:\windows\SYSTEM32\ntdll.dll
#12 0x in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

The hang never happens when using glibc's pthread implementation under Linux.

-- 
Sitsofe | http://sucs.org/~sits/
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Deadlock in winpthreads' pthread_cond_signal()

Re: [Mingw-w64-public] Deadlock in winpthreads' pthread_cond_signal()

Re: [Mingw-w64-public] Deadlock in winpthreads' pthread_cond_signal()

Re: [Mingw-w64-public] Deadlock in winpthreads' pthread_cond_signal()

Re: [Mingw-w64-public] GCC Fallthrough warnings.

[Mingw-w64-public] Deadlock in winpthreads' pthread_cond_signal()

6 matches

Site Navigation

Mail list logo

Footer information