lkml.org 
[lkml]   [2006]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: BUG() in exit.c triggers in -git5
From
Date
On Thu, 2006-07-13 at 16:45 -0400, Dave Jones wrote:
> I saw this yesterday too, but was running a slightly older kernel.
> It's got the usual Fedora patches in there too, but I can't think
> of anything that would cause this off the top of my head.
> (Due to those patches the line number is skewed, it's
> actually pointing at..
>
> tsk->flags |= PF_DEAD;
>
> schedule();
> this-> BUG();
> /* Avoid "noreturn function does return". */
> for (;;) ;
>
> at line 954 in Linus' tree.
>
> Dave
>
> ----------- [cut here ] --------- [please bite here ] ---------
> Kernel BUG at kernel/exit.c:876
> invalid opcode: 0000 [1] SMP
> last sysfs file: /block/sda/sda1/size
> CPU 2
> Modules linked in: autofs4 hidp l2cap bluetooth nfs lockd nfs_acl sunrpc acpi_cpufreq vfat fat video sbs i2c_ec button battery asus_acpi ac radeon drm ipv6 parport_pc lp parport snd_intel8x0 snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_emu10k1 snd_rawmidi snd_ac97_codec floppy usb_storage snd_ac97_bus sg snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_pcm emu10k1_gp snd_seq_device ide_cd e752x_edac snd_timer e1000 gameport edac_mc i2c_i801 snd_page_alloc pcspkr i2c_core cdrom snd_util_mem uhci_hcd snd_hwdep ehci_hcd snd soundcore dm_snapshot dm_zero dm_mirror dm_mod ata_piix libata sd_mod scsi_mod ext3 jbd
> Pid: 8155, comm: formail Not tainted 2.6.17-1.2384.fc6 #1
> RIP: 0010:[<ffffffff802168fd>] [<ffffffff802168fd>] do_exit+0x906/0x912
> RSP: 0018:ffff81000f265ef8 EFLAGS: 00010246
> RAX: 0000000000000080 RBX: 0000000000000010 RCX: 0000000000000000
> RDX: ffffffff80269b52 RSI: 0000000000000000 RDI: ffff81000f271040
> RBP: ffff81000f265f38 R08: 0000000000000001 R09: 0000000000000001
> R10: 0000000000000001 R11: ffff810002627418 R12: ffff81000f271040
> R13: ffff810037ffda60 R14: 0000000000000001 R15: 0000000000000000
> FS: 0000000000000000(0000) GS:ffff81003fe3b560(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00002aaaaaac7000 CR3: 0000000000201000 CR4: 00000000000006e0
> Process formail (pid: 8155, threadinfo ffff81000f264000, task ffff81000f271040)
> Stack: ffff81003fe1e040 ffff81000f271178 0000000000000000 00002aaaab28b878
> 0000000000000000 00007fffcb88c420 0000000000000000 0000000000000000
> ffff81000f265f68 ffffffff8024c2ed 0000000000000000 00002aaaab28b878
> Call Trace:


> [<ffffffff8024c2ed>] debug_mutex_init+0x0/0x43

Looking at the above call trace, I have to say things are really screwed
up. You somehow called do_exit with a return path to debug_mutex_init?
I wonder if you somehow had a system call reference some null pointer,
and then it exited the call and produced this. There might have been
code to wake up the process, but because of a previous bug, it was just
about to exit. Are you sure there wasn't another dump before this?

Maybe we should add a BUG or WARN_ON in try_to_wake_up if we are waking
up a process that is already dead.

-- Steve


>
> Code: 0f 0b 68 4c fb 49 80 c2 6c 03 eb fe 55 ba 40 00 00 00 89 f0
> RIP [<ffffffff802168fd>] do_exit+0x906/0x912
> RSP <ffff81000f265ef8>
> <1>Fixing recursive fault but reboot is needed!
>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-07-17 02:23    [from the cache]
©2003-2011 Jasper Spaans