| Summary: | gcc crashed unexpecdedly when used with a cluster kernel "openmosix-sources-2.4.32" && with dinamic process migration | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | kerzol <kerzolster> |
| Component: | [OLD] Core system | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | major | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
kerzol
2006-04-24 20:38:32 UTC
*** Bug 130460 has been marked as a duplicate of this bug. *** Not interested in gcc-3.3.6 bugs. Reopen if you can reproduce the problem w/ latest stable gcc. Please note that this problem is not gcc-specific, but rather kernel-specific. I believe the kernel isn't supposed to catch ``kernel NULL pointer dereference'' when running non-privileged user programs, so I think the bug should be re-opened. Indeed, the very same happens with some other processes as well, e. g.: Apr 18 15:40:55 darkside kernel: <1>Unable to handle kernel NULL pointer dereference at virtual address 0000004c Apr 18 15:40:55 darkside kernel: printing eip: Apr 18 15:40:55 darkside kernel: c017146d Apr 18 15:40:55 darkside kernel: *pde = 00000000 Apr 18 15:40:55 darkside kernel: Oops: 0002 Apr 18 15:40:55 darkside kernel: CPU: 0 Apr 18 15:40:55 darkside kernel: EIP: 0010:[set_brk+61/176] Not tainted Apr 18 15:40:55 darkside kernel: EIP: 0010:[<c017146d>] Not tainted Apr 18 15:40:55 darkside kernel: EFLAGS: 00010286 Apr 18 15:40:55 darkside kernel: eax: 00000000 ebx: 00000000 ecx: 0804e988 edx: 00000000 Apr 18 15:40:55 darkside kernel: esi: 0804f000 edi: 0804f000 ebp: cabb5d34 esp: cabb5b24 Apr 18 15:40:55 darkside kernel: ds: 0018 es: 0018 ss: 0018 Apr 18 15:40:55 darkside kernel: Process mpirun (pid: 8036, stackpage=cabb5000) Apr 18 15:40:55 darkside kernel: Stack: cabb5b28 00000000 00000000 c76c84c0 0804e000 c01734f9 0804e5d0 0804e988 Apr 18 15:40:55 darkside kernel: 000005d0 00000003 00001812 00000006 c840a7bb c995107c 00000001 00004d27 Apr 18 15:40:55 darkside kernel: 00000020 00000296 c7905080 cae5e400 cae5e400 00000000 00000002 000005d0 Apr 18 15:40:55 darkside kernel: Call Trace: [load_elf_binary+1065/4064] [inet_recvmsg+80/112] [load_elf_binary+0/4064] [search_binary_handler+308/464] [do_execve+329/800] Apr 18 15:40:55 darkside kernel: Call Trace: [<c01734f9>] [<c023faf0>] [<c01730d0>] [<c015a524>] [<c015a709>] Apr 18 15:40:55 darkside kernel: [sys_execve+66/128] [call_with_regs+75/148] [deputy_syscall+499/688] [sys_execve+0/128] [deputy_main_loop+897/1376] [mosix_pre_usermode_actions+138/176] Apr 18 15:40:55 darkside kernel: [<c01079f2>] [<c010ba7f>] [<c0196d33>] [<c01079b0>] [<c0195751>] [<c019c00a>] Apr 18 15:40:55 darkside kernel: [straight_to_mosix+5/13] Apr 18 15:40:55 darkside kernel: [<c010b95a>] Apr 18 15:40:55 darkside kernel: Apr 18 15:40:55 darkside kernel: Code: 89 78 4c 89 78 48 31 c0 8b 5c 24 08 8b 74 24 0c 8b 7c 24 10 However, I will upgrade gcc and report whether it still breaks or not. Well, if your kernel randomly crashes when running random processes, then check your hardware first (RAM, overheating, etc.) (In reply to comment #4) > Well, if your kernel randomly crashes when running random processes, > then check your hardware first (RAM, overheating, etc.) The crashes aren't completely random (look at the call traces below), so the processes. Indeed, the system runs quite stable when process migration is disabled, and it looks like the processes crash just after the migration is done. > Apr 15 14:49:03 darkside kernel: Process > gcc (pid: 3523, stackpage=c9a6d000) ... > Apr 15 14:49:03 darkside kernel: Call Trace: > [load_elf_binary+1065/4064] [inet_recvmsg+80/112] > [load_elf_binary+0/4064] [search_binary_handler+308/464] > [do_execve+329/800] > Apr 18 15:40:55 darkside kernel: Process > mpirun (pid: 8036, stackpage=cabb5000) ... > Apr 18 15:40:55 darkside kernel: Call Trace: > [load_elf_binary+1065/4064] [inet_recvmsg+80/112] > [load_elf_binary+0/4064] [search_binary_handler+308/464] > [do_execve+329/800] |