Bug 923486 - find utils test-lock
find utils test-lock
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
201502*
PowerPC-64 openSUSE 13.2
: P5 - None : Normal (vote)
: ---
Assigned To: Dinar Valeev
E-mail List
https://sourceware.org/bugzilla/show_...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-03-20 22:48 UTC by Dinar Valeev
Modified: 2015-11-04 15:36 UTC (History)
12 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
debugmno.patch (2.16 KB, patch)
2015-06-19 13:08 UTC, Michel Normand
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dinar Valeev 2015-03-20 22:48:38 UTC
In Staging:A test-lock fails

[  113s] Starting test_lock ... OK
[  114s] Starting test_rwlock .../bin/sh: line 5: 18641 Aborted                 EXEEXT='' srcdir='.' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_FR='fr_FR' LOCALE_TR_UTF8='tr_TR.UTF-8' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_JA='ja_JP' LOCALE_ZH_CN='zh_CN.GB18030' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_TR_UTF8='tr_TR.UTF-8' LOCALE_ZH_CN='zh_CN.GB18030' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_JA='ja_JP' LOCALE_ZH_CN='zh_CN.GB18030' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_ZH_CN='zh_CN.GB18030' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_JA='ja_JP' LOCALE_ZH_CN='zh_CN.GB18030' abs_aux_dir='/home/abuild/rpmbuild/BUILD/findutils-4.5.14/build-aux' abs_aux_dir='/home/abuild/rpmbuild/BUILD/findutils-4.5.14/build-aux' MAKE='make' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_JA='ja_JP' LOCALE_ZH_CN='zh_CN.GB18030' ${dir}$tst
[  114s] FAIL: test-lock

jfyi: libidn have the same failure
Comment 1 Bernhard Wiedemann 2015-03-22 05:44:13 UTC
so is this a problem in findutils/libidn, libc or kernel?
Comment 2 Michel Normand 2015-03-23 08:35:35 UTC
I tried in my tumbleweed guest and the osc build passed with no error.
===
osc co openSUSE:Factory:Staging:A findutils
cd openSUSE:Factory:Staging:A/findutils 
osc build
WARNING: package is not existing on server yet
WARNING: source service from package or project will not be executed. This may not be the same build as on server!
Building findutils.spec for standard/ppc64le
...
[  193s] Starting test_lock ... OK
[  194s] Starting test_rwlock ... OK
[  195s] Starting test_recursive_lock ... OK
[  197s] Starting test_once ... OK
...
[  208s] All 214 tests passed
...
[  235s] twppc64le finished "build findutils.spec" at Mon Mar 23 08:03:13 UTC 2015.
===
Comment 3 Dinar Valeev 2015-03-23 12:45:25 UTC
I'm stil able to reproduce it with local build even in chroot
Comment 4 Takashi Iwai 2015-03-24 13:51:16 UTC
What if you manually run test-lock?  Does it still abort?
Comment 5 Dinar Valeev 2015-03-24 13:56:10 UTC
Let me try
Comment 6 Dinar Valeev 2015-03-24 15:43:12 UTC
yes.

./test-lock 
Starting test_lock ... OK
Starting test_rwlock ...Aborted
Comment 7 Takashi Iwai 2015-03-24 16:16:57 UTC
So rwlock doesn't work expected, indeed, by some reason.  It must be from the abort() call in check_accounts().

Is the code compiled properly with HAVE_PTHREAD_RWLOCK & co?
Comment 8 Dinar Valeev 2015-03-24 16:19:33 UTC
grep HAVE_PTHREAD_* config.h
#define HAVE_PTHREAD_ATFORK 1
#define HAVE_PTHREAD_MUTEX_RECURSIVE 1
#define HAVE_PTHREAD_RWLOCK 1
Comment 9 Takashi Iwai 2015-03-24 16:28:27 UTC
OK, then what about PTHREAD_IN_USE_DETECTION_HARD?

You can take a look at gl/lib/glthread/lock.h.  This defined pthread_in_use(), and this might be wrongly false.  Then the whole glthread code disables the pthread *silently*.

# if HAVE_PTHREAD_RWLOCK
#  ifdef PTHREAD_RWLOCK_INITIALIZER
typedef pthread_rwlock_t gl_rwlock_t;
#   define gl_rwlock_define(STORAGECLASS, NAME) \
      STORAGECLASS pthread_rwlock_t NAME;
#   define gl_rwlock_define_initialized(STORAGECLASS, NAME) \
      STORAGECLASS pthread_rwlock_t NAME = gl_rwlock_initializer;
#   define gl_rwlock_initializer \
      PTHREAD_RWLOCK_INITIALIZER
#   define glthread_rwlock_init(LOCK) \
      (pthread_in_use () ? pthread_rwlock_init (LOCK, NULL) : 0)
#   define glthread_rwlock_rdlock(LOCK) \
      (pthread_in_use () ? pthread_rwlock_rdlock (LOCK) : 0)
....

Either there some configuration error, or pthread rwlock is really broken on ppc64le.  Hopefully the former.
Comment 10 Dinar Valeev 2015-03-24 16:36:09 UTC
grep PTHREAD_IN_USE_DETECTION_HARD config.h
/* #undef PTHREAD_IN_USE_DETECTION_HARD */
Comment 11 Takashi Iwai 2015-03-24 16:41:56 UTC
(In reply to Dinar Valeev from comment #10)
> grep PTHREAD_IN_USE_DETECTION_HARD config.h
> /* #undef PTHREAD_IN_USE_DETECTION_HARD */

And USE_POSIX_THREADS is defined, right?  (Also USE_POSIX_THREADS_WEAK.)
It'd be interesting to see whether any these configure results are different from other architectures.  If they are same, the code path should be identical, and it implies that the problem is in pthread.
Comment 12 Dinar Valeev 2015-03-24 16:44:14 UTC
Yes.
grep USE_POSIX_THREADS config.h
#define USE_POSIX_THREADS 1
#define USE_POSIX_THREADS_WEAK 1


@Michel did you managed to reproduce that issue locally?
Comment 13 Michel Normand 2015-03-24 17:06:04 UTC
(In reply to Dinar Valeev from comment #12)
> [CUT] ...
> 
> @Michel did you managed to reproduce that issue locally?

no I did not reproduced locally, even if it seems that I have 
the same defines as you have:
===
$grep -E 'PTHREAD|USE_POSIX_THREADS' /mnt/disk3/build-root/standard-ppc64le/home/abuild/rpmbuild/BUILD/findutils-4.5.14/config.h
#define HAVE_PTHREAD_ATFORK 1
/* Define if the <pthread.h> defines PTHREAD_MUTEX_RECURSIVE. */
#define HAVE_PTHREAD_MUTEX_RECURSIVE 1
#define HAVE_PTHREAD_RWLOCK 1
#define HAVE_RAW_DECL_PTHREAD_SIGMASK 1
/* #undef PTHREAD_IN_USE_DETECTION_HARD */
#define USE_POSIX_THREADS 1
#define USE_POSIX_THREADS_WEAK 1
#ifndef _POSIX_PTHREAD_SEMANTICS
# define _POSIX_PTHREAD_SEMANTICS 1
===
...
[  193s] Starting test_lock ... OK
[  194s] Starting test_rwlock ... OK
[  195s] Starting test_recursive_lock ... OK
===
Comment 14 Chenzi Cao 2015-04-06 07:48:52 UTC
Hi Andreas, would you please kindly help to have a look at here? I'm not quite sure whether it is right to assign it to you, please feel free to reassign whenever necessary, thank you!
Comment 15 Andreas Schwab 2015-04-07 08:52:47 UTC
Staging:A is currently empty and findutils doesn't fail in my ~:Factory project.  Is this still an issue?  I've seen spurious failures in the past on ppc64le due to broken build workers.
Comment 16 Andreas Schwab 2015-04-09 15:22:47 UTC
That looks like a broken build worker.
Comment 17 Dinar Valeev 2015-04-24 11:55:52 UTC
seems to be a glitch
Comment 18 Michel Normand 2015-06-18 12:35:32 UTC
again a new occurrence of same failure at:
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:PowerPC/findutils/standard/ppc64le as  extracted below.
The only difference versus initial problem is the additional message:
"audit: printk limit exceeded"
I do not know if that could be the root cause.
===
[  111s] Starting test_lock ... OK
[  112s] Starting test_rwlock ...audit: printk limit exceeded
[  112s] /bin/sh: line 5: 18697 Aborted                 EXEEXT='' srcdir='.' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_FR='fr_FR' LOCALE_TR_UTF8='tr_TR.UTF-8' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_JA='ja_JP' LOCALE_ZH_CN='zh_CN.GB18030' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_TR_UTF8='tr_TR.UTF-8' LOCALE_ZH_CN='zh_CN.GB18030' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_JA='ja_JP' LOCALE_ZH_CN='zh_CN.GB18030' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_ZH_CN='zh_CN.GB18030' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_JA='ja_JP' LOCALE_ZH_CN='zh_CN.GB18030' abs_aux_dir='/home/abuild/rpmbuild/BUILD/findutils-4.5.14/build-aux' abs_aux_dir='/home/abuild/rpmbuild/BUILD/findutils-4.5.14/build-aux' MAKE='make' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_JA='ja_JP' LOCALE_ZH_CN='zh_CN.GB18030' ${dir}$tst
[  112s] FAIL: test-lock
===
Comment 19 Michel Normand 2015-06-18 12:49:40 UTC
To complete my comment #18 
The problem is not specific to gcc5:
===
This failure was on worker:
build95 started "build findutils.spec" at Thu Jun 18 05:30:02 UTC 2015. 
[104/115] cumulate gcc-5-1.59

While the initial failure was on worker:
build96 started "build findutils.spec" at Fri Mar 20 17:16:42 UTC 2015.
[98/109] cumulate gcc-4.8-12.3
===
Comment 20 Dinar Valeev 2015-06-18 12:51:16 UTC
Both are Power8 machines
Comment 21 Michel Normand 2015-06-18 13:59:29 UTC
I noticed the following, but do not make any conclusion yet:

* The two failing OBS logs have qemu setup with: -smp 8,threads=4
* If I create ppc64le guest on my local power8 PKVM 2.1.1
  I do have failure when qemu setup with: -smp 8,sockets=1,cores=2,threads=4
  I do passed tests when qemu setup with: -smp 4,sockets=1,cores=1,threads=8
Comment 22 Dinar Valeev 2015-06-18 14:04:32 UTC
The change was done due to doxygen was failing to build if threads value was equal or greater than smp
Comment 23 Michel Normand 2015-06-19 07:39:16 UTC
* try to redo failure in chroot env with ulimit set to generate core file
  need a while loop to ultimately failed (need between 30 to 50 trials)
* as reported in data below the abort is an explicit call in gl_rwlock_rdlock
  because glthread_rwlock_rdlock() is reporting an error.
* Need to continue investigation from there.

===
abuild@vm64:~/rpmbuild/BUILD/findutils-4.5.14/tests> ulimit -c unlimited
abuild@vm64:~/rpmbuild/BUILD/findutils-4.5.14/tests> while test 1 ; do ./test-lock || break;done
Starting test_lock ... OK
Starting test_rwlock ... OK
Starting test_recursive_lock ... OK
Starting test_once ... OK
...                       
Starting test_lock ... OK
Starting test_rwlock ... OK
Starting test_recursive_lock ... OK
Starting test_once ... OK
Starting test_lock ... OK
Starting test_rwlock ...Aborted (core dumped)
abuild@vm64:~/rpmbuild/BUILD/findutils-4.5.14/tests> file core
core: ELF 64-bit LSB core file 64-bit PowerPC or cisco 7500, version 1 (SYSV), SVR4-style, from './test-lock'
abuild@vm64:~/rpmbuild/BUILD/findutils-4.5.14/tests> gdb -c core ./test-lock
...
Core was generated by `./test-lock '.
Program terminated with signal SIGABRT, Aborted.
#0  0x00003fffb185cf1c in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: zypper install glibc-debuginfo-2.21-6.25.ppc64le
(gdb) bt
#0  0x00003fffb185cf1c in raise () from /lib64/libc.so.6        
#1  0x00003fffb185f034 in abort () from /lib64/libc.so.6         
#2  0x0000000010002038 in rwlock_checker_thread (arg=<optimized out>) at test-lock.c:265
#3  0x00003fffb19f7fb8 in start_thread () from /lib64/libpthread.so.0
#4  0x00003fffb1930414 in clone () from /lib64/libc.so.6
(gdb) frame 2
#2  0x0000000010002038 in rwlock_checker_thread (arg=<optimized out>) at test-lock.c:265
265           gl_rwlock_rdlock(my_rwlock);
(gdb) info reg pc lr
pc             0x10002038       0x10002038 <rwlock_checker_thread+264>
lr             0x10002038       0x10002038 <rwlock_checker_thread+264>
(gdb) disas $pc-12,+20
Dump of assembler code from 0x1000202c to 0x10002040:
   0x000000001000202c <rwlock_checker_thread+252>:      cmpwi   cr7,r9,4000
   0x0000000010002030 <rwlock_checker_thread+256>:      beq     cr7,0x10001fd0 <rwlock_checker_thread+160>
   0x0000000010002034 <rwlock_checker_thread+260>:      bl      0x10000cb0 <00000043.plt_call.abort@@GLIBC_2.17>
=> 0x0000000010002038 <rwlock_checker_thread+264>:      ld      r2,24(r1)
   0x000000001000203c <rwlock_checker_thread+268>:      li      r3,0
End of assembler dump.
===
findutils-4.5.14/tests/test-lock.c:265: gl_rwlock_rdlock (my_rwlock);
findutils-4.5.14/gl/lib/glthread/lock.h:859: abort ();
===
Comment 24 Michel Normand 2015-06-19 13:08:45 UTC
Created attachment 638534 [details]
debugmno.patch

To continue my investigation in comment #23
> * try to redo failure in chroot env with ulimit set to generate core file
>   need a while loop to ultimately failed (need between 30 to 50 trials)
> * as reported in data below the abort is an explicit call in gl_rwlock_rdlock
>   because glthread_rwlock_rdlock() is reporting an error.
> * Need to continue investigation from there.
>

* The day after with new osc build and chroot env the abort is now in
  rwlock_checker_thread as reported by core extract below.
* applying the debugmno.patch and doing a while loop of ./test-lock
  confirm that the failure is random (39 failures on 866 trials)
  but this time always in same check_accounts function.
* Note that doing same tests loop on fedora fc22 do not report such error.
===
@vm64:/home/michel/work/openSUSE:Factory:PowerPC/findutils]
$target=/mnt/disk3/build-root/standard-ppc64le/
$for xx in dev sys proc; do sudo mount -o bind /$xx $target/$xx;done
$osc chroot
abuild@vm64:~> cd rpmbuild/BUILD/findutils-4.5.14/tests/
abuild@vm64:~/rpmbuild/BUILD/findutils-4.5.14/tests> ulimit -c unlimited
abuild@vm64:~/rpmbuild/BUILD/findutils-4.5.14/tests> idx=1; failure=0; while test 1 ; do echo "=== trial: $idx: failure: $failure"; ./test-lock || ((failure++)); ((idx++)); done
...
=== trial: 24: failure: 0
Starting test_lock ... OK
Starting test_rwlock ...check_accounts: sum=4006, expected 4000
check_accounts: sum=4006, expected 4000 
check_accounts: sum=4006, expected 4000
check_accounts: sum=4006, expected 4000
Aborted (core dumped)
=== trial: 25: failure: 1
=== trial: 616: failure: 29
Starting test_lock ... OK
Starting test_rwlock ...check_accounts: sum=3994, expected 4000
check_accounts: sum=3994, expected 4000 
check_accounts: sum=3994, expected 4000
check_accounts: sum=3994, expected 4000
Aborted (core dumped)
=== trial: 617: failure: 30
=== trial: 866: failure: 39
Comment 25 Takashi Iwai 2015-06-19 14:09:50 UTC
This looks to me more like a problem of glibc.  Or possibly kernel, but glibc is the first suspect.

Could you check whether the older glibc (e.g. SLE12) causes the same problem?
Comment 26 Michel Normand 2015-06-26 08:50:31 UTC
(In reply to Takashi Iwai from comment #25)
> This looks to me more like a problem of glibc.  Or possibly kernel, but
> glibc is the first suspect.
> 
> Could you check whether the older glibc (e.g. SLE12) causes the same problem?

* on my opensuse_13_2_ppc64le guest do an osc build of findutils
  and used generated test-lock outside and inside chroot environment
  as detailed below.
* Conclusion:
  with glibc-2.19-16.2.2 pass with  old libraries.
  with glibc-2.21-6.25   failure with last tumbleweed libraries.

===
=== old libraries:
===
[michel@opensuse_13_2_ppc64le :~/work/openSUSE:Factory:PowerPC/findutils]
$rpm -qa |grep glibc
glibc-2.19-16.2.2.ppc64le
glibc-devel-2.19-16.2.2.ppc64le
glibc-extra-2.19-16.2.2.ppc64le
glibc-locale-2.19-16.2.2.ppc64le
linux-glibc-devel-3.16-2.3.1.noarch
$cd  $target/home/abuild/rpmbuild/BUILD/findutils-4.5.14/tests/
[michel@opensuse_13_2_ppc64le:/mnt/disk3/build-root/standard-ppc64le/home/abuild/rpmbuild/BUILD/findutils-4.5.14/tests]
$idx=1; while test 1 ; do echo "=== trial: $idx"; ./test-lock || break; ((idx++)); done
...
=== trial: 268
set pragma: USE_POSIX_THREADS, USE_POSIX_THREADS_WEAK, HAVE_PTHREAD_RWLOCK, PTHREAD_RWLOCK_INITIALIZER, HAVE_PTHREAD_MUTEX_RECURSIVE,
Starting test_lock ... OK
Starting test_rwlock ... OK
Starting test_recursive_lock ...^C <= stopped manually
===
=== new libraries (in chroot env)
===
abuild@opensuse_13_2_ppc64le:~/rpmbuild/BUILD/findutils-4.5.14/tests> ldd ./test-lock
        linux-vdso64.so.1 (0x00003fff81ef0000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00003fff81ea0000)
        libc.so.6 => /lib64/libc.so.6 (0x00003fff81cd0000)
        /lib64/ld64.so.2 (0x0000000052400000)
abuild@opensuse_13_2_ppc64le:~/rpmbuild/BUILD/findutils-4.5.14/tests> rpm -qa |grep glibc
glibc-2.21-6.25.ppc64le
glibc-devel-2.21-6.25.ppc64le
glibc-locale-2.21-6.25.ppc64le
linux-glibc-devel-4.0-1.74.noarch
abuild@opensuse_13_2_ppc64le:~/rpmbuild/BUILD/findutils-4.5.14/tests> idx=1;  while test 1 ; do echo "=== trial: $idx:"; ./test-lock || break; ((idx++)); done
...
=== trial: 14:
set pragma: USE_POSIX_THREADS, USE_POSIX_THREADS_WEAK, HAVE_PTHREAD_RWLOCK, PTHREAD_RWLOCK_INITIALIZER, HAVE_PTHREAD_MUTEX_RECURSIVE,
Starting test_lock ... OK
Starting test_rwlock ...check_accounts: sum=4006, expected 4000
check_accounts: sum=4006, expected 4000
check_accounts: sum=4006, expected 4000
check_accounts: sum=4006, expected 4000
check_accounts: sum=4006, expected 4000
Aborted
===
Comment 27 Michel Normand 2015-06-26 11:28:24 UTC
(In reply to Michel Normand from comment #21)
> * The two failing OBS logs have qemu setup with: -smp 8,threads=4
> * If I create ppc64le guest on my local power8 PKVM 2.1.1
>   I do have failure when qemu setup with: -smp 8,sockets=1,cores=2,threads=4
>   I do passed tests when qemu setup with: -smp 4,sockets=1,cores=1,threads=8

To complete above comments, I made some tests with different cpu/thread configs
to confirm that there is no failure if sockets or cores/socket remain set to 1
But failure if socket or cores/sockets are greater than 1
===
summary:                                        opensuse     fedora fc22
                                                (tumbleweed)
qemu                               lscpu        ppc64le
                                   cpu th co so test-lock    test-lock
-smp 4,sockets=1,cores=2,threads=4 4   4  1  1  ----------   ----------
                                   4   2  2  1  KO trial 2   ----------
-smp 8,sockets=1,cores=2,threads=4 8   4  2  1  KO trial 2   OK >trial 677
-smp 8,sockets=2,cores=1,threads=4 8   4  1  2  KO trial 2
-smp 8,sockets=1,cores=4,threads=2 8   2  4  1  KO trial 1
-smp 8,sockets=1,cores=1,threads=8 8   8  1  1  OK >trial 200
===
Comment 28 Michel Normand 2015-07-08 10:36:46 UTC
If glibc rebuilt with --disable-lock-elision (patch of spec file) and related rpms used to build and test findutils, then no errors are reported trying to test in loop the above test-lock.

So findutils failure reported by this bug #923486 is probably
a side effect of request #285070 (1) referenced in glibc revisions (2)

(1) https://build.opensuse.org/request/show/285070
(2) https://build.opensuse.org/package/revisions/Base:System/glibc
Comment 29 Michel Normand 2015-07-08 13:48:07 UTC
(In reply to Michel Normand from comment #28)
> If glibc rebuilt with --disable-lock-elision (patch of spec file) and
> related rpms used to build and test findutils, then no errors are reported
> trying to test in loop the above test-lock.
> 
> So findutils failure reported by this bug #923486 is probably
> a side effect of request #285070 (1) referenced in glibc revisions (2)
> 
> (1) https://build.opensuse.org/request/show/285070
> (2) https://build.opensuse.org/package/revisions/Base:System/glibc

Andreas and Dinar question for you:

* Would it be acceptable as a workaround to have glibc rebuilt
  with patched spec to --disable-lock-elision specifically for ppc64le ?
  At least above shows this is sufficient to avoid findutils test-lock failure.

* Above shows we have a problem with lock elision.
  It could be a problem with the kernel, gcc or binutils
  provided with OpenSuse, but glibc is most likely the culprit.
Comment 30 Andreas Schwab 2015-07-09 09:51:35 UTC
Does that still happen with the latest glibc (see home:Andreas_Schwab:glibc)?
Comment 31 Michel Normand 2015-07-09 12:04:06 UTC
(In reply to Andreas Schwab from comment #30)
> Does that still happen with the latest glibc (see home:Andreas_Schwab:glibc)?

* findutils test-lock is still failing the same way with ppc64le glibc rpms 
  from (1)
* the latest glibc source in (2) do not build yet for ppc64le

(1) https://build.opensuse.org/package/binaries/home:Andreas_Schwab:glibc/glibc?repository=p  (glibc-2.21.90-517.1.ppc64le.rpm ...)
(2) https://build.opensuse.org/package/show/home:Andreas_Schwab:glibc/glibc
Comment 32 Andreas Schwab 2015-07-09 12:18:23 UTC
So someone needs to look and fix lock elision on ppc64le for 2.22.
Comment 33 Michel Normand 2015-07-09 12:56:26 UTC
(In reply to Andreas Schwab from comment #32)
> So someone needs to look and fix lock elision on ppc64le for 2.22.

Could it be acceptable to disable lock-elision for glibc opensuse build of ppc64le as suggested by request 315619 (1) while someone is able to fix it ?

(1) https://build.opensuse.org/request/show/315619
Comment 34 Tulio Magno Quites Machado Filho 2015-07-09 13:09:11 UTC
(In reply to Andreas Schwab from comment #32)
> So someone needs to look and fix lock elision on ppc64le for 2.22.

I'm taking a look at this.
Comment 35 Mike Wolf 2015-07-24 16:57:07 UTC
A preliminary fix to this problem has been identified and fixing the problem stated in this bug.  However it is believed that more work needs to be done to fully fix all issues in this area.  The developer working on the solution is wondering if this is a blocking problem for openSUSE?  Should we make the preliminary patch available?
Comment 36 Andreas Schwab 2015-07-27 07:05:20 UTC
As the current OBS build worker configurations don't appear to trigger the problem there is no hurry.
Comment 37 Michel Normand 2015-07-29 15:36:25 UTC
(In reply to Mike Wolf from comment #35)
> A preliminary fix to this problem has been identified and fixing the problem
> stated in this bug.  However it is believed that more work needs to be done
> to fully fix all issues in this area.  The developer working on the solution
> is wondering if this is a blocking problem for openSUSE?  Should we make the
> preliminary patch available?

only for tracking purpose, the related LTC bug is 127388, previously created because did not know how to create proxy bug from this opensuse bug.
Comment 38 Tulio Magno Quites Machado Filho 2015-07-30 17:01:53 UTC
This bug has been reported in the glibc bugzilla: 
https://sourceware.org/bugzilla/show_bug.cgi?id=18743

And a patch has been submitted to the community:
https://sourceware.org/ml/libc-alpha/2015-07/msg00982.html
Comment 39 Michel Normand 2015-09-24 07:38:05 UTC
(In reply to Tulio Magno Quites Machado Filho from comment #38)
> This bug has been reported in the glibc bugzilla: 
> https://sourceware.org/bugzilla/show_bug.cgi?id=18743
> 
> And a patch has been submitted to the community:
> https://sourceware.org/ml/libc-alpha/2015-07/msg00982.html

only for update: the patch is still waiting approval upstream:
https://sourceware.org/ml/libc-alpha/2015-09/msg00336.html
Comment 40 Bernhard Wiedemann 2015-10-05 11:00:13 UTC
This is an autogenerated message for OBS integration:
This bug (923486) was mentioned in
https://build.opensuse.org/request/show/336491 Factory / glibc
Comment 41 Tulio Magno Quites Machado Filho 2015-10-19 19:05:25 UTC
This patch has been accepted upstream:
https://sourceware.org/git/?p=glibc.git;a=commit;h=6ec52bf634b7650b57ff67b5f5053bce8992d549
Comment 42 Michel Normand 2015-10-28 12:50:42 UTC
change status to fixed as per comment #40 and comment #41