Bug#738575: pthread: segfault in libpthread on Intel Galileo board
On Mon, Jan 01, 2001 at 12:23:05AM +0000, Thomas Faust wrote:
> Package: libc6
> Version: 2.13-38
> Severity: normal
> File: pthread
>
> Dear Maintainer,
>
> I bootstrapped a Debian base system via "debootstrap --arch i386 wheezy ./newfiles http://http.debian.net/debian/"; and put it on a Galileo board. On the Galileo board there new Intel Quark IA processor - which is basically a 486 with some instructions extensions from Pentium.
> If I boot the existing Galileo kernel with the bootstrapped fileset, many applications crash with a segfault in pthread.
> To reporduce, follow the instruction on https://communities.intel.com/message/220080
> Here are ways to reproduce consistently - many other apps show the same behavior
> 1. Boot the system, create a new user (non root), connect to the board via ssh - the sshd will crash with a segfault in pthread
> 2. Do a 'apt-get install cowsay' - at the end, apt-get will crash with a segfault in pthread
>
> sshd[2519]: segfault at b7173107 ip b714f07b sp bf97ea94 error ffff0007 in libpthread-2.13.so[b714a000+15000]
>
> incorrect behavior: segfault - applications stop working
> expected behavior: no crash
>
> uname -a = Linux galileo 3.8.7-yocto-standard #1 Wed Jan 15 00:21:32 CET 2014 i586 GNU/Linux
> dpkg -s libc6 = 2.13-38
The problem happens in __nptl_setxid, at address 0x507b:
00005060 <__nptl_setxid>:
5060: 55 push %ebp
5061: 31 c0 xor %eax,%eax
5063: 89 e5 mov %esp,%ebp
5065: b9 01 00 00 00 mov $0x1,%ecx
506a: 57 push %edi
506b: 56 push %esi
506c: 53 push %ebx
506d: 83 ec 14 sub $0x14,%esp
5070: e8 fb f3 ff ff call 4470 <__i686.get_pc_thunk.bx>
5075: 81 c3 7f 0f 01 00 add $0x10f7f,%ebx
=> 507b: f0 0f b1 8b 94 21 00 lock cmpxchg %ecx,0x2194(%ebx)
5082: 00
5083: 0f 85 b6 17 00 00 jne 683f <_L_lock_743>
5089: 8b 45 08 mov 0x8(%ebp),%eax
508c: 8b b3 38 01 00 00 mov 0x138(%ebx),%esi
Despite the name __i686.get_pc_thunk.bx is fine on this CPU (it
actually has been rename to __x86.get_pc_thunk.bx on recent GCC
versions), as it is only get the PC through the stack with a movl
instruction:
00004470 <__i686.get_pc_thunk.bx>:
4470: 8b 1c 24 mov (%esp),%ebx
4473: c3 ret
So the question is if the "lock cmpxchg" instruction is behaving
correctly on the Intel Quark. This should be supported according
to the developer's manual.
It might be difficult to investigate more without access to such a CPU.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: