Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 11 Feb 2004 10:11:34 -0800 (PST)
From:      Kevin Martin <sigma@pair.com>
To:        freebsd-gnats-submit@FreeBSD.org
Subject:   i386/62699: fstat randomly crashes with "out of memory"
Message-ID:  <200402111811.i1BIBYMH080042@www.freebsd.org>
Resent-Message-ID: <200402111820.i1BIKFHW013638@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         62699
>Category:       i386
>Synopsis:       fstat randomly crashes with "out of memory"
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-i386
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Feb 11 10:20:14 PST 2004
>Closed-Date:
>Last-Modified:
>Originator:     Kevin Martin
>Release:        4.8-STABLE
>Organization:
pair Networks, Inc
>Environment:
FreeBSD koloda.pair.com 4.8-STABLE FreeBSD 4.8-STABLE #0: Fri Oct  3 11:10:15 EDT 2003     sigma@koloda.pair.com:/usr/src/sys/compile/PAIRqm  i386
>Description:
About 1 in every 1000 runs, "fstat" will die with "Out of memory".  The problem has been traced to line 349 of fstat.c 1.21.2.7, where filed.fd_lastfile occasionally gets a huge, incorrect value, and subsequently tries to malloc several gigabytes to hold the array of files.
>How-To-Repeat:
#!/bin/csh
while (1)
fstat >/dev/null
end

Watch for "Out of memory" instances.
>Fix:
A workaround is simply to insert a sanity check that fd_lastfile is less than, say, 100000.  A more elegant workaround would be a comparison to the real size of the file table.  A real fix would be to find out why garbage ends up in the filed structure, which is read via KVM_READ just a few lines earlier.

>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200402111811.i1BIBYMH080042>