Bug 62930 - Use of mlockall(2) causes erratic behavior in subsequent programs
Summary: Use of mlockall(2) causes erratic behavior in subsequent programs
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: Bruce M Simpson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-02-16 21:30 UTC by Dan van Pelt
Modified: 2004-05-08 06:34 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dan van Pelt 2004-02-16 21:30:20 UTC
A program which calls mlockall(2) without calling munlockall(2) before it exits seems to cause the OS to randomly deliver SIGBUS to other programs not only running in the shell that ran the original offending program but also in separate shells that are running under different UIDs.

Fix: 

Making sure the application calls munlockall(2) before it exits seems to alleviate this behavior, but I'm not sure this is really a fix since AFAIK, the application shouldn't need to call munlockall(2) before exiting.
How-To-Repeat: First, compile the following and run as root:

---------------------
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>

int main (void)
{
  if (mlockall(MCL_CURRENT|MCL_FUTURE) < 0)
    fprintf(stderr,"mlockall(2) failed.\n");

  return (0);
}
---------------------

At this point, subsequent commands issued to the shell will periodically and randomly fail with the following:

neutrino# ls
Bus error (core dumped)
neutrino#

You may have to run 'ls' (or another command) twenty or more times before the command finally fails.  I have tested this on other systems to verify that it wasn't my hardware.  The time (# of calls) that it takes the command to fail doesn't seem to vary much based on avail. memory, et al.
Comment 1 Kris Kennaway freebsd_committer freebsd_triage 2004-02-17 10:32:24 UTC
Responsible Changed
From-To: freebsd-bugs->bms

bms wrote the mlockall() support
Comment 2 Brian Feldman freebsd_committer freebsd_triage 2004-04-27 02:08:21 UTC
I'm suffering from this problem quite a bit at work.  The pmap_extract() 
that is called from vm_fault_unwire() fails.  I don't think you're even 
allowed to call pmap_extract() and expect it to succeed.  We really need to 
fix this one before 5.3.

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green@FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\
Comment 3 Alan Cox freebsd_committer freebsd_triage 2004-05-08 06:31:12 UTC
State Changed
From-To: open->closed

vm/vm_map.c revision 1.334 corrects the principal problem reported 
herein; specify, problems resulting from the use of mlockall(2) 
without a munlockall(2) prior to exiting the process.