Bug 207314 - Oops/lockup in anon_vma_link()
Summary: Oops/lockup in anon_vma_link()
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: 209119
TreeView+ depends on / blocked
 
Reported: 2006-09-20 16:46 UTC by Jan Kratochvil
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-10-12 13:20:16 UTC
Type: ---
Embargoed:


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

Description Jan Kratochvil 2006-09-20 16:46:36 UTC
Description of problem:
Oops while trying to reproduce Bug 206813.

Version-Release number of selected component (if applicable):
kernel-2.6.17-1.2647.fc6
gdb-6.5-8.fc6
ElectricFence-2.2.2-20.2.2

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 16:46:40 UTC
Created attachment 136755 [details]
Oops log

Comment 2 Peter Zijlstra 2006-10-11 09:02:16 UTC
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 13:20:16 UTC
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.