Althought, it is undefined behavior, there is no reason for segfault.
Signed-off-by: Leonid Lisovskiy lly.dev@gmail.com --- libpthread/linuxthreads/mutex.c | 3 ++- test/pthread/ex8-mtx-odd.c | 56 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 58 insertions(+), 1 deletion(-) create mode 100644 test/pthread/ex8-mtx-odd.c
diff --git a/libpthread/linuxthreads/mutex.c b/libpthread/linuxthreads/mutex.c index 8908414..8cb779b 100644 --- a/libpthread/linuxthreads/mutex.c +++ b/libpthread/linuxthreads/mutex.c @@ -171,7 +171,8 @@ int attribute_hidden __pthread_mutex_unlock(pthread_mutex_t * mutex) { switch (mutex->__m_kind) { case PTHREAD_MUTEX_ADAPTIVE_NP: - __pthread_unlock(&mutex->__m_lock); + if (mutex->__m_lock.__status != 0) + __pthread_unlock(&mutex->__m_lock); return 0; case PTHREAD_MUTEX_RECURSIVE_NP: if (mutex->__m_owner != thread_self()) diff --git a/test/pthread/ex8-mtx-odd.c b/test/pthread/ex8-mtx-odd.c new file mode 100644 index 0000000..791b2c2 --- /dev/null +++ b/test/pthread/ex8-mtx-odd.c @@ -0,0 +1,56 @@ +/* Copyright (C) 2002 Free Software Foundation, Inc. + This file is part of the GNU C Library. + Contributed by Ulrich Drepper drepper@redhat.com, 2002. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA. */ + +#include <errno.h> +#include <pthread.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <time.h> + + +static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER; + +static int +do_test (void) +{ + + if (pthread_mutex_lock (&lock) != 0) + { + puts ("mutex_lock failed"); + exit (1); + } + + if (pthread_mutex_unlock (&lock) != 0) + { + puts ("1st mutex_unlock failed"); + exit (1); + } + + if (pthread_mutex_unlock (&lock) != 0) + { + puts ("2nd mutex_unlock failed"); + exit (1); + } + + return 0; +} + +#define TEST_FUNCTION do_test () +#include "../test-skeleton.c"
Hi Leonid, Leonid Lisovskiy wrote,
Althought, it is undefined behavior, there is no reason for segfault.
Signed-off-by: Leonid Lisovskiy lly.dev@gmail.com
libpthread/linuxthreads/mutex.c | 3 ++- test/pthread/ex8-mtx-odd.c | 56 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 58 insertions(+), 1 deletion(-) create mode 100644 test/pthread/ex8-mtx-odd.c
diff --git a/libpthread/linuxthreads/mutex.c b/libpthread/linuxthreads/mutex.c index 8908414..8cb779b 100644 --- a/libpthread/linuxthreads/mutex.c +++ b/libpthread/linuxthreads/mutex.c @@ -171,7 +171,8 @@ int attribute_hidden __pthread_mutex_unlock(pthread_mutex_t * mutex) { switch (mutex->__m_kind) { case PTHREAD_MUTEX_ADAPTIVE_NP:
- __pthread_unlock(&mutex->__m_lock);
- if (mutex->__m_lock.__status != 0)
return 0; case PTHREAD_MUTEX_RECURSIVE_NP: if (mutex->__m_owner != thread_self())__pthread_unlock(&mutex->__m_lock);
Unfortunately this seems to break crisv32 support. (qemu-system-cris) The ex1 test is failing (never ends).
You can either verify this directly with OpenADK or embedded-test.sh from embedded-test.org: mksh embedded-test.sh --arch=crisv32 --debug --libc=uclibc-ng --test=libc --libc-source=uclibc-ng/
uclibc-ng directory is latest git with your linuxthreads.old patches.
Any idea? On which arch you have tested?
best regards Waldemar
On Thu, May 26, 2016 at 12:41 AM, Waldemar Brodkorb wbx@uclibc-ng.org wrote:
Unfortunately this seems to break crisv32 support. (qemu-system-cris) The ex1 test is failing (never ends).
You can either verify this directly with OpenADK or embedded-test.sh from embedded-test.org: mksh embedded-test.sh --arch=crisv32 --debug --libc=uclibc-ng --test=libc --libc-source=uclibc-ng/
Can I get complete kernel+initramfs+rootfs images for QEMU crisv32 somewhere to investigate problem on my site?
uclibc-ng directory is latest git with your linuxthreads.old patches.
Any idea? On which arch you have tested?
I tested it on mips32 & x86 platforms. No idea at this moment, I must to drill down linuxthreads.old internals to understand strange side effects.
Leonid
On Thu, May 26, 2016 at 10:45 AM, Leonid Lisovskiy lly.dev@gmail.com wrote:
On Thu, May 26, 2016 at 12:41 AM, Waldemar Brodkorb wbx@uclibc-ng.org wrote:
Unfortunately this seems to break crisv32 support. (qemu-system-cris) The ex1 test is failing (never ends).
Any idea? On which arch you have tested?
I wasn't take into account that problem arise on platforms that has HAS_COMPARE_AND_SWAP defined only. cris is not in this list. Seems to problem come from original glibc sources and we have to fix __pthread_unlock() itself.
Will post new version of patch after some tests.
Leonid
Hi Leonid, Leonid Lisovskiy wrote,
On Thu, May 26, 2016 at 10:45 AM, Leonid Lisovskiy lly.dev@gmail.com wrote:
On Thu, May 26, 2016 at 12:41 AM, Waldemar Brodkorb wbx@uclibc-ng.org wrote:
Unfortunately this seems to break crisv32 support. (qemu-system-cris) The ex1 test is failing (never ends).
Any idea? On which arch you have tested?
I wasn't take into account that problem arise on platforms that has HAS_COMPARE_AND_SWAP defined only. cris is not in this list. Seems to problem come from original glibc sources and we have to fix __pthread_unlock() itself.
Will post new version of patch after some tests.
Thanks. Providing the CRIS image wouldn't be so simple, as neither strace nor gdbserver works at the moment. So I am not sure it would help.
Is there a reason you use LT on X86 or MIPS? Both have NPTL support. Normally LT is only enabled for noMMU architectures as BFIN/FR-V/C6X/Xtensa and for some exotic architectures AVR32/CRIS and for some architectures NPTL support wasn't ported from Glibc as M68k/Microblate/NIOS2.
Don't get me wrong, I am happy to have someone fixing LT bugs :) If you think LT is useful for NPTL supported architectures speak up.
best regards Waldemar
On Thu, May 26, 2016 at 10:13 PM, Waldemar Brodkorb wbx@uclibc-ng.org wrote:
Is there a reason you use LT on X86 or MIPS? Both have NPTL support. Normally LT is only enabled for noMMU architectures as BFIN/FR-V/C6X/Xtensa and for some exotic architectures AVR32/CRIS and for some architectures NPTL support wasn't ported from Glibc as M68k/Microblate/NIOS2.
The single reason for LT.old on such platforms - historical builds based on kernel 2.4. Not really used in our project at now, but I'm sure that it is good to push fixes into upstream.
Regards, Leonid