This is the mail archive of the
glibc-bugs@sources.redhat.com
mailing list for the glibc project.
[Bug libc/466] New: mqueue tests segfault
- From: "soenketesch at gmx dot de" <sourceware-bugzilla at sources dot redhat dot com>
- To: glibc-bugs at sources dot redhat dot com
- Date: 22 Oct 2004 17:31:47 -0000
- Subject: [Bug libc/466] New: mqueue tests segfault
- Reply-to: sourceware-bugzilla at sources dot redhat dot com
The rt/tst-mqueue-tests segfault, all of them on mq_open() as far as I can see.
The Linux kernel messages below are from tst-mqueue-1, tst-mqueue-2 and
tst-mqueue-3.
glibc-20041018, compiled with gcc 3.4.2 on Linux 2.6.9. Configured with
--disable-profile --enable-add-ons=nptl --with-tls --with-__thread
--enable-kernel=2.6.0 --without-cvs
ksymoops 2.4.9 on i686 2.6.9. Options used
-v ../linux-2.6.9/vmlinux (specified)
-K (specified)
-L (specified)
-O (specified)
-m ../linux-2.6.9/System.map (specified)
<1>Unable to handle kernel NULL pointer dereference at virtual address 00000010
c01d48f3
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c01d48f3>] Not tainted VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202 (2.6.9)
eax: 00000000 ebx: c93df000 ecx: 00000000 edx: 00000004
esi: 00000000 edi: b7ffe768 ebp: 00000004 esp: c92cff98
ds: 007b es: 007b ss: 0068
Stack: bfffef99 000002a4 c0127cc4 00000000 000000c1 01800004 bfffef99 bfffef78
b7ffe768 c92ce000 c010424b bfffef99 000000c1 00000180 bfffef78 b7ffe768
bfffef30 00000115 0000007b 0000007b 00000115 b7ffbfe2 00000073 00000202
Call Trace:
[<c0127cc4>] sys_setpgid+0x1e4/0x1f0
[<c010424b>] syscall_call+0x7/0xb
Code: 3d 18 fc ff ff 89 c3 0f 97 c0 0f b6 f0 89 d8 85 f6 0f 85 cd 00 00 00 e8 3c
a7 f7 ff 85 c0 89 c5 0f 88 ab 00 00 00 a1 ac 8b 3a c0 <8b> 40 10 8b 40 08 8d 48
68 ff 48 68 0f 88 50 0b 00 00 b9 ff ff
>>EIP; c01d48f3 <sys_mq_open+53/1c0> <=====
>>ebx; c93df000 <pg0+9029000/3fc48400>
>>esp; c92cff98 <pg0+8f19f98/3fc48400>
Trace; c0127cc4 <sys_setpgid+1e4/1f0>
Trace; c010424b <syscall_call+7/b>
This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.
Code; c01d48c8 <sys_mq_open+28/1c0>
00000000 <_EIP>:
Code; c01d48c8 <sys_mq_open+28/1c0>
0: 3d 18 fc ff ff cmp $0xfffffc18,%eax
Code; c01d48cd <sys_mq_open+2d/1c0>
5: 89 c3 mov %eax,%ebx
Code; c01d48cf <sys_mq_open+2f/1c0>
7: 0f 97 c0 seta %al
Code; c01d48d2 <sys_mq_open+32/1c0>
a: 0f b6 f0 movzbl %al,%esi
Code; c01d48d5 <sys_mq_open+35/1c0>
d: 89 d8 mov %ebx,%eax
Code; c01d48d7 <sys_mq_open+37/1c0>
f: 85 f6 test %esi,%esi
Code; c01d48d9 <sys_mq_open+39/1c0>
11: 0f 85 cd 00 00 00 jne e4 <_EIP+0xe4>
Code; c01d48df <sys_mq_open+3f/1c0>
17: e8 3c a7 f7 ff call fff7a758 <_EIP+0xfff7a758>
Code; c01d48e4 <sys_mq_open+44/1c0>
1c: 85 c0 test %eax,%eax
Code; c01d48e6 <sys_mq_open+46/1c0>
1e: 89 c5 mov %eax,%ebp
Code; c01d48e8 <sys_mq_open+48/1c0>
20: 0f 88 ab 00 00 00 js d1 <_EIP+0xd1>
Code; c01d48ee <sys_mq_open+4e/1c0>
26: a1 ac 8b 3a c0 mov 0xc03a8bac,%eax
This decode from eip onwards should be reliable
Code; c01d48f3 <sys_mq_open+53/1c0>
00000000 <_EIP>:
Code; c01d48f3 <sys_mq_open+53/1c0> <=====
0: 8b 40 10 mov 0x10(%eax),%eax <=====
Code; c01d48f6 <sys_mq_open+56/1c0>
3: 8b 40 08 mov 0x8(%eax),%eax
Code; c01d48f9 <sys_mq_open+59/1c0>
6: 8d 48 68 lea 0x68(%eax),%ecx
Code; c01d48fc <sys_mq_open+5c/1c0>
9: ff 48 68 decl 0x68(%eax)
Code; c01d48ff <sys_mq_open+5f/1c0>
c: 0f 88 50 0b 00 00 js b62 <_EIP+0xb62>
Code; c01d4905 <sys_mq_open+65/1c0>
12: b9 .byte 0xb9
Code; c01d4906 <sys_mq_open+66/1c0>
13: ff (bad)
Code; c01d4907 <sys_mq_open+67/1c0>
14: ff .byte 0xff
<1>Unable to handle kernel NULL pointer dereference at virtual address 00000010
c01d48f3
*pde = 00000000
Oops: 0000 [#2]
CPU: 0
EIP: 0060:[<c01d48f3>] Not tainted VLI
EFLAGS: 00010202 (2.6.9)
eax: 00000000 ebx: c8c7b000 ecx: 00000000 edx: 00000004
esi: 00000000 edi: b7ffe768 ebp: 00000004 esp: c8ed1f98
ds: 007b es: 007b ss: 0068
Stack: bfffef99 c0107005 00000000 c0330800 0000001a 01800004 bfffef99 bfffef78
b7ffe768 c8ed0000 c010424b bfffef99 000000c2 00000180 bfffef78 b7ffe768
bfffee78 00000115 0000007b 0000007b 00000115 b7ffbfe2 00000073 00000202
Call Trace:
[<c0107005>] do_IRQ+0x115/0x140
[<c010424b>] syscall_call+0x7/0xb
Code: 3d 18 fc ff ff 89 c3 0f 97 c0 0f b6 f0 89 d8 85 f6 0f 85 cd 00 00 00 e8 3c
a7 f7 ff 85 c0 89 c5 0f 88 ab 00 00 00 a1 ac 8b 3a c0 <8b> 40 10 8b 40 08 8d 48
68 ff 48 68 0f 88 50 0b 00 00 b9 ff ff
>>EIP; c01d48f3 <sys_mq_open+53/1c0> <=====
>>ebx; c8c7b000 <pg0+88c5000/3fc48400>
>>esp; c8ed1f98 <pg0+8b1bf98/3fc48400>
Trace; c0107005 <do_IRQ+115/140>
Trace; c010424b <syscall_call+7/b>
This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.
Code; c01d48c8 <sys_mq_open+28/1c0>
00000000 <_EIP>:
Code; c01d48c8 <sys_mq_open+28/1c0>
0: 3d 18 fc ff ff cmp $0xfffffc18,%eax
Code; c01d48cd <sys_mq_open+2d/1c0>
5: 89 c3 mov %eax,%ebx
Code; c01d48cf <sys_mq_open+2f/1c0>
7: 0f 97 c0 seta %al
Code; c01d48d2 <sys_mq_open+32/1c0>
a: 0f b6 f0 movzbl %al,%esi
Code; c01d48d5 <sys_mq_open+35/1c0>
d: 89 d8 mov %ebx,%eax
Code; c01d48d7 <sys_mq_open+37/1c0>
f: 85 f6 test %esi,%esi
Code; c01d48d9 <sys_mq_open+39/1c0>
11: 0f 85 cd 00 00 00 jne e4 <_EIP+0xe4>
Code; c01d48df <sys_mq_open+3f/1c0>
17: e8 3c a7 f7 ff call fff7a758 <_EIP+0xfff7a758>
Code; c01d48e4 <sys_mq_open+44/1c0>
1c: 85 c0 test %eax,%eax
Code; c01d48e6 <sys_mq_open+46/1c0>
1e: 89 c5 mov %eax,%ebp
Code; c01d48e8 <sys_mq_open+48/1c0>
20: 0f 88 ab 00 00 00 js d1 <_EIP+0xd1>
Code; c01d48ee <sys_mq_open+4e/1c0>
26: a1 ac 8b 3a c0 mov 0xc03a8bac,%eax
This decode from eip onwards should be reliable
Code; c01d48f3 <sys_mq_open+53/1c0>
00000000 <_EIP>:
Code; c01d48f3 <sys_mq_open+53/1c0> <=====
0: 8b 40 10 mov 0x10(%eax),%eax <=====
Code; c01d48f6 <sys_mq_open+56/1c0>
3: 8b 40 08 mov 0x8(%eax),%eax
Code; c01d48f9 <sys_mq_open+59/1c0>
6: 8d 48 68 lea 0x68(%eax),%ecx
Code; c01d48fc <sys_mq_open+5c/1c0>
9: ff 48 68 decl 0x68(%eax)
Code; c01d48ff <sys_mq_open+5f/1c0>
c: 0f 88 50 0b 00 00 js b62 <_EIP+0xb62>
Code; c01d4905 <sys_mq_open+65/1c0>
12: b9 .byte 0xb9
Code; c01d4906 <sys_mq_open+66/1c0>
13: ff (bad)
Code; c01d4907 <sys_mq_open+67/1c0>
14: ff .byte 0xff
<1>Unable to handle kernel NULL pointer dereference at virtual address 00000010
c01d48f3
*pde = 00000000
Oops: 0000 [#3]
CPU: 0
EIP: 0060:[<c01d48f3>] Not tainted VLI
EFLAGS: 00010202 (2.6.9)
eax: 00000000 ebx: c8cbe000 ecx: 00000000 edx: 00000000
esi: 00000000 edi: b7ffe768 ebp: 00000004 esp: c8405f98
ds: 007b es: 007b ss: 0068
Stack: bfffef99 00000000 00001000 00000003 00000000 01800004 bfffef99 bfffef78
b7ffe768 c8404000 c010424b bfffef99 000000c2 00000180 bfffef78 b7ffe768
bfffdef8 00000115 0000007b 0000007b 00000115 b7ffbfe2 00000073 00000202
Call Trace:
[<c010424b>] syscall_call+0x7/0xb
Code: 3d 18 fc ff ff 89 c3 0f 97 c0 0f b6 f0 89 d8 85 f6 0f 85 cd 00 00 00 e8 3c
a7 f7 ff 85 c0 89 c5 0f 88 ab 00 00 00 a1 ac 8b 3a c0 <8b> 40 10 8b 40 08 8d 48
68 ff 48 68 0f 88 50 0b 00 00 b9 ff ff
>>EIP; c01d48f3 <sys_mq_open+53/1c0> <=====
>>ebx; c8cbe000 <pg0+8908000/3fc48400>
>>esp; c8405f98 <pg0+804ff98/3fc48400>
Trace; c010424b <syscall_call+7/b>
This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.
Code; c01d48c8 <sys_mq_open+28/1c0>
00000000 <_EIP>:
Code; c01d48c8 <sys_mq_open+28/1c0>
0: 3d 18 fc ff ff cmp $0xfffffc18,%eax
Code; c01d48cd <sys_mq_open+2d/1c0>
5: 89 c3 mov %eax,%ebx
Code; c01d48cf <sys_mq_open+2f/1c0>
7: 0f 97 c0 seta %al
Code; c01d48d2 <sys_mq_open+32/1c0>
a: 0f b6 f0 movzbl %al,%esi
Code; c01d48d5 <sys_mq_open+35/1c0>
d: 89 d8 mov %ebx,%eax
Code; c01d48d7 <sys_mq_open+37/1c0>
f: 85 f6 test %esi,%esi
Code; c01d48d9 <sys_mq_open+39/1c0>
11: 0f 85 cd 00 00 00 jne e4 <_EIP+0xe4>
Code; c01d48df <sys_mq_open+3f/1c0>
17: e8 3c a7 f7 ff call fff7a758 <_EIP+0xfff7a758>
Code; c01d48e4 <sys_mq_open+44/1c0>
1c: 85 c0 test %eax,%eax
Code; c01d48e6 <sys_mq_open+46/1c0>
1e: 89 c5 mov %eax,%ebp
Code; c01d48e8 <sys_mq_open+48/1c0>
20: 0f 88 ab 00 00 00 js d1 <_EIP+0xd1>
Code; c01d48ee <sys_mq_open+4e/1c0>
26: a1 ac 8b 3a c0 mov 0xc03a8bac,%eax
This decode from eip onwards should be reliable
Code; c01d48f3 <sys_mq_open+53/1c0>
00000000 <_EIP>:
Code; c01d48f3 <sys_mq_open+53/1c0> <=====
0: 8b 40 10 mov 0x10(%eax),%eax <=====
Code; c01d48f6 <sys_mq_open+56/1c0>
3: 8b 40 08 mov 0x8(%eax),%eax
Code; c01d48f9 <sys_mq_open+59/1c0>
6: 8d 48 68 lea 0x68(%eax),%ecx
Code; c01d48fc <sys_mq_open+5c/1c0>
9: ff 48 68 decl 0x68(%eax)
Code; c01d48ff <sys_mq_open+5f/1c0>
c: 0f 88 50 0b 00 00 js b62 <_EIP+0xb62>
Code; c01d4905 <sys_mq_open+65/1c0>
12: b9 .byte 0xb9
Code; c01d4906 <sys_mq_open+66/1c0>
13: ff (bad)
Code; c01d4907 <sys_mq_open+67/1c0>
14: ff .byte 0xff
--
Summary: mqueue tests segfault
Product: glibc
Version: unspecified
Status: NEW
Severity: critical
Priority: P2
Component: libc
AssignedTo: gotom at debian dot or dot jp
ReportedBy: soenketesch at gmx dot de
CC: glibc-bugs at sources dot redhat dot com
GCC host triplet: i686-pc-linux-gnu
http://sources.redhat.com/bugzilla/show_bug.cgi?id=466
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.