Bug 207314 - Oops/lockup in anon_vma_link()
Oops/lockup in anon_vma_link()
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
Depends On:
Blocks: 209119
  Show dependency treegraph
Reported: 2006-09-20 12:46 EDT by Jan Kratochvil
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-12 09:20:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Oops log (2.53 KB, text/plain)
2006-09-20 12:46 EDT, Jan Kratochvil
no flags Details

  None (edit)
Description Jan Kratochvil 2006-09-20 12:46:36 EDT
Description of problem:
Oops while trying to reproduce Bug 206813.

Version-Release number of selected component (if applicable):

How reproducible:
Did not try.

Steps to Reproduce:
1. EF_ALLOW_MALLOC_0=1 LD_PRELOAD=/usr/lib/libefence.so gdb ./bla
2. b inner_main
3. run
4. On (incorrect) "guile> " prompt try to CTRL-C/kill gdb.
Actual results:
Attached oops, ps(1) commands and others start locking up.

Expected results:
Non-crashed kernel.

Additional info:
This kernel has still many crashes on SMP, it runs fine with "maxcpus=1".
Comment 1 Jan Kratochvil 2006-09-20 12:46:40 EDT
Created attachment 136755 [details]
Oops log
Comment 2 Peter Zijlstra 2006-10-11 05:02:16 EDT
Hi Jan, I'm having trouble reproducing this (kernel-2_6_18-1_2725_el5 i686 UP).

[root@plop ~]# wc -l /proc/`pidof gdb`/maps
9256 /proc/2524/maps
[root@plop ~]# wc -l /proc/`pidof bla`/maps
6998 /proc/2527/maps

which is a lot but not unexpected given ElectricFence.
Would you mind trying if you can reproduce with a recent FC/RHEL kernel?
Comment 3 Jan Kratochvil 2006-10-12 09:20:16 EDT
Unable to reproduce it myself, tried only on kernel-xen-2.6.18-1.2747.fc6.i686,
though (the original bugreport was against native non-XEN kernel).

Even the common crashes for SMP / maxcpus>1 got fixed even on non-XEN kernels
since that time so it could be just a consequence.

Thanks for the reproducibility attempt. It could be probablt also CLOSED as RAWHIDE.

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