Bug 155817 - FC3 32bit objects causes FC3.91(tc4T2) to oops x86_64
Summary: FC3 32bit objects causes FC3.91(tc4T2) to oops x86_64
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: FC4Blocker
TreeView+ depends on / blocked
 
Reported: 2005-04-23 23:09 UTC by Tom Mitchell
Modified: 2015-01-04 22:19 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-01 21:42:57 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
additional Oops from /var/log/messages after rawhide yum update today. (4.75 KB, text/plain)
2005-04-25 04:07 UTC, Tom Mitchell
no flags Details
Current output of lsmod (1.73 KB, text/plain)
2005-04-27 05:26 UTC, Tom Mitchell
no flags Details

Description Tom Mitchell 2005-04-23 23:09:30 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-1.3.1 Firefox/1.0.3

Description of problem:
ggc hello.c on FC3(32bit) generates and a.out that causes
a FC3.91 oops.

ldd a.out also gneerates an Oops


Version-Release number of selected component (if applicable):
kernel-2.6.11-1.1261_FC4

How reproducible:
Always

Steps to Reproduce:
1. gcc hello.c on 32bit fc3
2. scp a.out to the x86_64 box
3. on the x86_64 box... run it   $ ./a.out
  

Actual Results:  Oops in /varl/log/messages
a.out[3069]: segfault at 00000000ffffe01c rip 00000000002fa575 rsp 00000000ffffc47c error 4
Apr 23 15:48:37 xtl2 kernel: Unable to handle kernel paging request at 00000000ffffe02c RIP:
Apr 23 15:48:37 xtl2 kernel: <ffffffff80131b0c>{elf_core_dump+1596}
Apr 23 15:48:37 xtl2 kernel: PGD 26b9c067 PUD 2604b067 PMD 269c0067 PTE 0
Apr 23 15:48:37 xtl2 kernel: Oops: 0000 [8]


Expected Results:   hello world

Additional info:

 kernel: a.out[3069]: segfault at 00000000ffffe01c rip 00000000002fa575 rsp 00000000ffffc47c error 4
Apr 23 15:48:37 xtl2 kernel: Unable to handle kernel paging request at 00000000ffffe02c RIP:
Apr 23 15:48:37 xtl2 kernel: <ffffffff80131b0c>{elf_core_dump+1596}
Apr 23 15:48:37 xtl2 kernel: PGD 26b9c067 PUD 2604b067 PMD 269c0067 PTE 0
Apr 23 15:48:37 xtl2 kernel: Oops: 0000 [8]
Apr 23 15:48:37 xtl2 kernel: CPU 0
Apr 23 15:48:37 xtl2 kernel: Modules linked in: sunrpc ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables ohci1394 ieee1394 ohci_hcd ehci_hcd i2c_nforce2 i2c_core snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc forcedeth 8139too mii floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod sata_nv libata sd_mod scsi_mod
Apr 23 15:48:37 xtl2 kernel: Pid: 3069, comm: checka.out Not tainted 2.6.11-1.1261_FC4
Apr 23 15:48:37 xtl2 kernel: RIP: 0010:[<ffffffff80131b0c>] <ffffffff80131b0c>{elf_core_dump+1596}
Apr 23 15:48:37 xtl2 kernel: RSP: 0018:ffff810026b77ba8  EFLAGS: 00010286
Apr 23 15:48:37 xtl2 kernel: RAX: ffff8100287d6810 RBX: 0000000000000000 RCX: ffff810026b77f58
Apr 23 15:48:37 xtl2 kernel: RDX: ffff81002664f380 RSI: ffff8100287d6810 RDI: ffff81003d9b8d70
Apr 23 15:48:37 xtl2 kernel: RBP: ffff810026b77c68 R08: 0000000000000000 R09: ffff81003d9b8d70
Apr 23 15:48:37 xtl2 kernel: R10: 0000000000000205 R11: ffffffff80229740 R12: ffffffff80476200
Apr 23 15:48:37 xtl2 kernel: R13: ffff81002664f380 R14: ffff810026b77c68 R15: ffff8100292c6f58
Apr 23 15:48:37 xtl2 kernel: FS:  00002aaaaaace000(0000) GS:ffffffff80565d00(0000) knlGS:0000000000000000
Apr 23 15:48:37 xtl2 kernel: CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
Apr 23 15:48:37 xtl2 kernel: CR2: 00000000ffffe02c CR3: 0000000026070000 CR4: 00000000000006e0
Apr 23 15:48:37 xtl2 kernel: Process checka.out (pid: 3069, threadinfo ffff810026b76000, task ffff8100287d6810)
Apr 23 15:48:37 xtl2 kernel: Stack: 0000000000000000 ffffffff880783cf 0000000000000000 0000000000000000
Apr 23 15:48:37 xtl2 kernel:        ffff81002968fac8 ffff810026b77f58 000000000000000b 0000000000000000
Apr 23 15:48:37 xtl2 kernel:        ffff810026b77c58 ffffffffffffffff
Apr 23 15:48:37 xtl2 kernel: Call Trace:<ffffffff880783cf>{:ext3:ext3_setattr+479} <ffffffff8019e065>{do_truncate+101}
Apr 23 15:48:37 xtl2 kernel:        <ffffffff801aec5a>{do_coredump+2362} <ffffffff8013ba5b>{vprintk+1323}
Apr 23 15:48:37 xtl2 kernel:        <ffffffff8014e84e>{__dequeue_signal+510} <ffffffff80150486>{get_signal_to_deliver+4486}
Apr 23 15:48:37 xtl2 kernel:        <ffffffff8010e34d>{do_signal+157} <ffffffff80179def>{poison_obj+63}
Apr 23 15:48:37 xtl2 kernel:        <ffffffff8017a594>{cache_free_debugcheck+596} <ffffffff803b7770>{thread_return+0}
Apr 23 15:48:37 xtl2 kernel:        <ffffffff8010f759>{retint_signal+54}
Apr 23 15:48:37 xtl2 kernel:
Apr 23 15:48:37 xtl2 kernel: Code: 66 a1 2c e0 ff ff 00 00 00 00 0f b7 c0 03 42 50 41 c7 07 7f
Apr 23 15:48:37 xtl2 kernel: RIP <ffffffff80131b0c>{elf_core_dump+1596} RSP <ffff810026b77ba8>
Apr 23 15:48:37 xtl2 kernel: CR2: 00000000ffffe02c
Apr 23 15:48:37 xtl2 kernel:  <3>Debug: sleeping function called from invalid context at include/linux/rwsem.h:43
Apr 23 15:48:37 xtl2 kernel: in_atomic():0, irqs_disabled():1
Apr 23 15:48:37 xtl2 kernel:
Apr 23 15:48:37 xtl2 kernel: Call Trace:<ffffffff8013c315>{profile_task_exit+21} <ffffffff8013df12>{do_exit+34}
Apr 23 15:48:37 xtl2 kernel:        <ffffffff8029fd59>{do_unblank_screen+137} <ffffffff80124f66>{do_page_fault+1910}
Apr 23 15:48:37 xtl2 kernel:        <ffffffff8805e41c>{:jbd:do_get_write_access+1660} <ffffffff801a5d69>{__getblk+57}
Apr 23 15:48:37 xtl2 kernel:        <ffffffff80179def>{poison_obj+63} <ffffffff8017a594>{cache_free_debugcheck+596}
Apr 23 15:48:37 xtl2 kernel:        <ffffffff8010fa3d>{error_exit+0} <ffffffff80229740>{selinux_inode_permission+0}
Apr 23 15:48:37 xtl2 kernel:        <ffffffff80131b0c>{elf_core_dump+1596} <ffffffff80131a66>{elf_core_dump+1430}
Apr 23 15:48:37 xtl2 kernel:        <ffffffff880783cf>{:ext3:ext3_setattr+479} <ffffffff8019e065>{do_truncate+101}
Apr 23 15:48:37 xtl2 kernel:        <ffffffff801aec5a>{do_coredump+2362} <ffffffff8013ba5b>{vprintk+1323}
Apr 23 15:48:37 xtl2 kernel:        <ffffffff8014e84e>{__dequeue_signal+510} <ffffffff80150486>{get_signal_to_deliver+4486}
Apr 23 15:48:37 xtl2 kernel:        <ffffffff8010e34d>{do_signal+157} <ffffffff80179def>{poison_obj+63}
Apr 23 15:48:37 xtl2 kernel:        <ffffffff8017a594>{cache_free_debugcheck+596} <ffffffff803b7770>{thread_return+0}
Apr 23 15:48:37 xtl2 kernel:        <ffffffff8010f759>{retint_signal+54}

===
I am missing some 32 bit support  because "gcc -m32 hello.c" fails
when "gcc hello.c" generates a 64bit object that runs.  This detail
might help. 
But that is not excuse for an oops... ;-)

Comment 1 Tom Mitchell 2005-04-25 04:07:11 UTC
Created attachment 113621 [details]
additional Oops from /var/log/messages after rawhide yum update today.

Perhaps redundant but an additional Oops from /var/log/messages.
This is at the time I noticed that ulimit for core dumps was interesting.
I have also picked up some recent odds and ends from rawhide (yum update).

Comment 2 Tom Mitchell 2005-04-27 04:50:48 UTC
Today 2.6.11-1.1267_FC4 loaded and running (other rpms are rawhide current)
Result... Problem persists.
$ ./checka.out
Segmentation fault
$
$ ulimit -c unlimited
$ ./checka.out
Segmentation fault
$
Message from syslogd at Tue Apr 26 21:39:53 2005 ...
x2 kernel: Oops: 0000 [1]

Message from syslogd@x2 at Tue Apr 26 21:39:53 2005 ...
x2 kernel: CR2: 00000000ffffe02c

$ uname -a
Linux x2 2.6.11-1.1267_FC4 #1 Mon Apr 25 19:41:39 EDT 2005 x86_64 x86_64 x86_64
GNU/Linux
$ file checka.out
checka.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped

Cores are all size zero... despite ulimit.



Comment 3 Tom Mitchell 2005-04-27 05:26:04 UTC
Created attachment 113701 [details]
Current  output of lsmod

 lsmod output Kernel is 2.6.11-1.1267_FC4

Comment 4 Tom Mitchell 2005-05-01 19:37:59 UTC
The latest rawhide updates seem to have fixed this for me.
Was this a link loader/ glibc  change that helped? But nothing
in user space should oops....

Comment 5 Dave Jones 2005-05-01 21:42:57 UTC
just a 32bit syscall emulation vs execshield bug in the kernel.
this has been broken for quite a while, but only recently due to other changes
did it show up as a real bug.



Note You need to log in before you can comment on or make changes to this bug.