* Kernel BUG at "fs/exec.c":777
@ 2005-08-18 2:19 Marc Lehmann
2005-08-21 8:49 ` Andrew Morton
0 siblings, 1 reply; 4+ messages in thread
From: Marc Lehmann @ 2005-08-18 2:19 UTC (permalink / raw)
To: linux-kernel
(A courteasy CC: on replies would be appreciated, thanks)
Hi!
I get the above oops message (full details below) sometimes when running the
CVS version of "cv", a gtk+ image viewer.
I use kernel 2.6.12.5, but it occured on 2.6.11 that I ran earlier, too.
Unfortunately, it only happens during interactive use (or at least my
simple test scripts were unable to reproduce the behaviour yet).
cv is a perl/gtk script that uses the IO::AIO module. That module starts a
number of threads that basically emulate asynchronous I/O.
The oops happen when cv starts to move files (which it does by fork+exec
of /bin/mv, which is where it oopses). IO::AIO has an pthread_atfork
handler that recreates the aio threads after the fork (but doesn't kill
the threads before the fork). The forked process than does an exec() and
rarely oopses.
So what happens is:
pthread_create (4 or more times)
fork ("main" thread forks)
pthread_create (4 or more times)
exec ("main" thread execs)
... (very rarely oopses)
All in quick successsion.
fs/exec.c:777 is:
593 static inline int de_thread(struct task_struct *tsk)
...
776 if (!thread_group_empty(current))
777 BUG();
778 if (!thread_group_leader(current))
779 BUG();
780 return 0;
2.6.11 oopsed at the same BUG().
The system is an SMP dual opteron in 64 bit mode with gcc-3.3 (I think)
compiled kernel and the nvidia kernel module loaded (but the program only
does X calls, no direct gl access). If wanted, I can probably reproduce
that without the nvidia kernel module loaded.
If any other info is required to fix that bug I'll happily try to find
out or test things.
Thanks!
The complete OOPS is:
----------- [cut here ] --------- [please bite here ] ---------
Kernel BUG at "fs/exec.c":777
invalid operand: 0000 [1] SMP
CPU 0
Modules linked in: nls_utf8 nls_cp850 vfat fat loop nvidia tg3 snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_seq_midi snd_seq_midi_event snd_seq snd_emu10k1 snd_seq_device snd_util_mem snd_hwdep w83627hf i2c_sensor i2c_isa amd64_agp 3w_9xxx
Pid: 11032, comm: cv Tainted: P 2.6.12.5
RIP: 0010:[<ffffffff8017e47b>] <ffffffff8017e47b>{flush_old_exec+1531}
RSP: 0018:ffff810002cddd28 EFLAGS: 00010202
RAX: ffff81001d064a90 RBX: 0000000000000001 RCX: 0000000000000000
RDX: ffff81001d064910 RSI: ffff81003e501680 RDI: ffff81003fec4e80
RBP: ffff81002555ccc0 R08: ffffffff805b1880 R09: 0000000000000002
R10: 00000000ffffffff R11: ffff810001e104e0 R12: 00000000ffffffb0
R13: ffff81002577a8c0 R14: ffff81002577b0c8 R15: ffff81003e501680
FS: 00002aaaab1a7e10(0000) GS:ffffffff80576780(0000) knlGS:0000000056a06500
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000003563600 CR3: 0000000015335000 CR4: 00000000000006e0
Process cv (pid: 11032, threadinfo ffff810002cdc000, task ffff81001d064910)
Stack: 0000000100000101 ffffffff801a2eee 0000000000000080 ffff81001295e480
0000000000000080 ffff81002dfbd600 ffff810000000000 ffff81002dfbd600
000000001295e480 ffff81000a4c9b40
Call Trace:<ffffffff801a2eee>{dnotify_parent+46} <ffffffff8019f4a7>{load_elf_binary+1335}
<ffffffff80157fd3>{buffered_rmqueue+323} <ffffffff8019ef70>{load_elf_binary+0}
<ffffffff8017ea3e>{search_binary_handler+158} <ffffffff8017ed82>{do_execve+386}
<ffffffff8010e72a>{system_call+126} <ffffffff8010d181>{sys_execve+65}
<ffffffff8010eb4a>{stub_execve+106}
Code: 0f 0b 05 ec 42 80 ff ff ff ff 09 03 65 48 8b 04 25 00 00 00
RIP <ffffffff8017e47b>{flush_old_exec+1531} RSP <ffff810002cddd28>
nfs warning: mount version older than kernel
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ pcg@goof.com
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Kernel BUG at "fs/exec.c":777
2005-08-18 2:19 Kernel BUG at "fs/exec.c":777 Marc Lehmann
@ 2005-08-21 8:49 ` Andrew Morton
2005-08-21 23:30 ` Marc Lehmann
2005-08-21 23:37 ` Marc Lehmann
0 siblings, 2 replies; 4+ messages in thread
From: Andrew Morton @ 2005-08-21 8:49 UTC (permalink / raw)
To: Marc Lehmann; +Cc: linux-kernel
Marc Lehmann <schmorp@schmorp.de> wrote:
>
> If wanted, I can probably reproduce
> that without the nvidia kernel module loaded.
>
Yes, please do that, thanks.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Kernel BUG at "fs/exec.c":777
2005-08-21 8:49 ` Andrew Morton
@ 2005-08-21 23:30 ` Marc Lehmann
2005-08-21 23:37 ` Marc Lehmann
1 sibling, 0 replies; 4+ messages in thread
From: Marc Lehmann @ 2005-08-21 23:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Sun, Aug 21, 2005 at 01:49:45AM -0700, Andrew Morton <akpm@osdl.org> wrote:
> Marc Lehmann <schmorp@schmorp.de> wrote:
> >
> > If wanted, I can probably reproduce
> > that without the nvidia kernel module loaded.
> >
>
> Yes, please do that, thanks.
I tried a few times with booting into textmode (the X-server loads the
nvidia module) and running the oops script, and after the third try, I
get the oops again, but not afterwards (I kept running it on the same
machine).
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ pcg@goof.com
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Kernel BUG at "fs/exec.c":777
2005-08-21 8:49 ` Andrew Morton
2005-08-21 23:30 ` Marc Lehmann
@ 2005-08-21 23:37 ` Marc Lehmann
1 sibling, 0 replies; 4+ messages in thread
From: Marc Lehmann @ 2005-08-21 23:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Sun, Aug 21, 2005 at 01:49:45AM -0700, Andrew Morton <akpm@osdl.org> wrote:
> Marc Lehmann <schmorp@schmorp.de> wrote:
> >
> > If wanted, I can probably reproduce
> > that without the nvidia kernel module loaded.
> >
>
> Yes, please do that, thanks.
Ooops, you are not Alexander Nyberg :) Sorry, to give my previous reply
more context: I had a conversation with Alexander Nyberg who wanted to
debug this problem this weekend, and I gave detailed instructions on how
to reproduce it (which is a bit awkward). I also wrote a script that
doesn't rely on X running, but triggers the bug much less often (in fact,
only twice for me so far), and then it seems only the first time after
reboot (which *could* be caused by the very different timing of the
stat()-threads due to the extra disk access).
Let's see what Alexander found out (if he found time). The problem does
not happen (or is not reproducible) with newer IO::AIO releases, as that
one doesn't start threads in the child after the fork/before the exec.
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ pcg@goof.com
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-08-21 23:37 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-08-18 2:19 Kernel BUG at "fs/exec.c":777 Marc Lehmann
2005-08-21 8:49 ` Andrew Morton
2005-08-21 23:30 ` Marc Lehmann
2005-08-21 23:37 ` Marc Lehmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox