From owner-freebsd-bugs  Mon Jun  9 21:00:04 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id VAA06530
          for bugs-outgoing; Mon, 9 Jun 1997 21:00:04 -0700 (PDT)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id VAA06490;
          Mon, 9 Jun 1997 21:00:01 -0700 (PDT)
Resent-Date: Mon, 9 Jun 1997 21:00:01 -0700 (PDT)
Resent-Message-Id: <199706100400.VAA06490@hub.freebsd.org>
Resent-From: gnats (GNATS Management)
Resent-To: freebsd-bugs
Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, jin@iss-p1.lbl.gov
Received: from iss-p1.lbl.gov (iss-p1.lbl.gov [131.243.2.47])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA06263
          for <FreeBSD-gnats-submit@freebsd.org>; Mon, 9 Jun 1997 20:56:36 -0700 (PDT)
Received: (from jin@localhost)
	by iss-p1.lbl.gov (8.8.5/8.8.5) id UAA20118;
	Mon, 9 Jun 1997 20:56:35 -0700 (PDT)
Message-Id: <199706100356.UAA20118@iss-p1.lbl.gov>
Date: Mon, 9 Jun 1997 20:56:35 -0700 (PDT)
From: "Jin Guojun[ITG]" <jin@iss-p1.lbl.gov>
Reply-To: jin@iss-p1.lbl.gov
To: FreeBSD-gnats-submit@FreeBSD.ORG
X-Send-Pr-Version: 3.2
Subject: kern/3827: fopen/freopen fails on some binary files.
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


>Number:         3827
>Category:       kern
>Synopsis:       fopen/freopen fails on some binary files.
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jun  9 21:00:00 PDT 1997
>Last-Modified:
>Originator:     Jin Guojun[ITG]
>Organization:
>Release:        FreeBSD 3.0-970527-SNAP i386
>Environment:

	FreeBSD 3.0-970527-SNAP

>Description:

	freopen() fails on about 50% binary files. It causes application
	handing. The programs are used for reading images and processing
	for enhancement. The first part reads the header (Text).
	When read/fread hang, the top show that it uses all available CPU.
	If SMP is enabled, this hanging process will take about at least
	one minute to be killed. In non-SMP kernel, it can be killed
	immediately.
	In gdb, after freopen(), do "p ftell(fp)" will get bad memory error.
	open() has the same problem.
	The same application using "<" works OK. 

>How-To-Repeat:

	No regular pattern for such failure. Normally, for same reading code,
	keep adding more code after it (such as more subroutines), the reading
	code will hang at reading same binary file.

>Fix:
	
	

>Audit-Trail:
>Unformatted: