Date: Mon, 16 Feb 2004 13:28:30 -0800 (PST) From: Dan van Pelt <dvp@chem.wwu.edu> To: freebsd-gnats-submit@FreeBSD.org Subject: kern/62930: Use of mlockall(2) causes erratic behavior in subsequent programs Message-ID: <200402162128.i1GLSUbC051559@www.freebsd.org> Resent-Message-ID: <200402162130.i1GLULPb059008@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 62930
>Category: kern
>Synopsis: Use of mlockall(2) causes erratic behavior in subsequent programs
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Mon Feb 16 13:30:20 PST 2004
>Closed-Date:
>Last-Modified:
>Originator: Dan van Pelt
>Release: 5.2.1-RC2
>Organization:
>Environment:
FreeBSD neutrino 5.2.1-RC2 FreeBSD 5.2.1-RC2 #0: Fri Feb 13 23:37:00 PST 2004 dan@neutrino:/usr/src/sys/i386/compile/NEUTRINO i386
>Description:
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.
>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.
>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.
>Release-Note:
>Audit-Trail:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200402162128.i1GLSUbC051559>