Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#42591 - [glibc] x86_64 contains instructions not all processors use
Attached to Project:
Arch Linux
Opened by James Gilmore (gilmoreja) - Tuesday, 28 October 2014, 23:20 GMT
Last edited by Allan McRae (Allan) - Friday, 07 November 2014, 03:14 GMT
Opened by James Gilmore (gilmoreja) - Tuesday, 28 October 2014, 23:20 GMT
Last edited by Allan McRae (Allan) - Friday, 07 November 2014, 03:14 GMT
|
DetailsDescription:
I will be honest that I don't really understand what's going on here, so I hope you excuse me.. I will try my best to explain what I can. Please let me know if you need more information... I have been using a program called "linuxtrack" that is available from the AUR. I am unable to run it without jumping through some hoops. It appears that the program is unable to create/overwrite a file because of a processor instruction "xend" that my computer cannot understand. The program will crash, and terminal output will read "Illegal Instruction (core dumped)." Through discussion with the developer of this program and use of backtraces, the function "pthread_rwlock_unlock" from libpthread.so.0 (which is part of glibc) has the instruction XEND, which my processor does not support. Additional info: * package version(s) glibc-2.20-2 x86-64 * config and/or log files etc. Here is the thread on the linuxtrack bug tracker where we discussed this issue: https://code.google.com/p/linux-track/issues/detail?id=74 My system has an AMD FX-6100 processor. Steps to reproduce: 1. Install linuxtrack from the AUR. 2. Attempt to run ltr_gui 3. Program crashes. |
This task depends upon
I'd like to provide few more details concerning this bug...
The application triggered the problem having two nested writer locks/unlocks, in this fashion:
pthread_rwlock_wrlock
pthread_rwlock_wrlock
//do some writing
pthread_rwlock_unlock //here the writer lock is actually unlocked
pthread_rwlock_unlock //here the lock is free already - triggers the bug
That said, you can probably reproduce it just by calling pthread_rwlock_unlock on a pristine (unlocked) lock.
This is part of the pthread_rwlock_unlock gdb dump after the SIGILL:
Dump of assembler code for function pthread_rwlock_unlock:
0x00007ffff358e3c0 <+0>: mov r8,rdi
0x00007ffff358e3c3 <+3>: mov edi,DWORD PTR [rdi+0x18]
0x00007ffff358e3c6 <+6>: test edi,edi
0x00007ffff358e3c8 <+8>: jne 0x7ffff358e3e0 <pthread_rwlock_unlock+32>
0x00007ffff358e3ca <+10>: mov esi,DWORD PTR [r8+0x4]
0x00007ffff358e3ce <+14>: test esi,esi
0x00007ffff358e3d0 <+16>: jne 0x7ffff358e3e0 <pthread_rwlock_unlock+32>
=> 0x00007ffff358e3d2 <+18>: xend
0x00007ffff358e3d5 <+21>: xor eax,eax
0x00007ffff358e3d7 <+23>: ret
This is where the problem seems to be comming from:
//from glibc-2.20/sysdeps/x86/elide.h
#define ELIDE_UNLOCK(is_lock_free) \
({ \
int ret = 0; \
if (is_lock_free) \
{ \
_xend (); \
ret = 1; \
} \
ret; \
})
//from glibc-2.20/nptl/pthread_rwlock_unlock.c
if (ELIDE_UNLOCK (rwlock->__data.__writer == 0
&& rwlock->__data.__nr_readers == 0))
return 0;
It seems the problem was also noted at least here:
https://lists.debian.org/debian-glibc/2014/09/msg00076.html
Kind regards,
Michal Navratil
https://sourceware.org/bugzilla/show_bug.cgi?id=17561