Message-Id: <1153095493.17406.5.camel@localhost.localdomain>
Date:	Sun, 16 Jul 2006 20:18:13 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Dave Jones <davej@...hat.com>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: BUG() in exit.c triggers in -git5

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists