httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@gonzo.ben.algroup.co.uk>
Subject SCO bug
Date Tue, 26 Sep 1995 15:50:52 GMT
I thought people might be interested in this (SCO's response to the bug which
makes it necessary to dup() the incoming socket fd):

------------------------
fprintf(S) causes a core dump when used following a call to fdopen(S)

KEYWORDS: fprintf fdopen core dump segmentation violation sigsegv signal memcpy 
null address buffer _base _file open file descriptor fd stdio stdin stdout 
stderr memory fault _bufendtab fclose setbug setvbuf

RELEASE:  SCO UNIX System V/386 Release 3.2 Development System Version 4.2
	  SCO Open Desktop Development System Release 3.0

PROBLEM:  Using fdopen() to associate a stream with a existing file descriptor
	  can cause a subsequent fprintf() library call using this new file
	  stream to abnormally terminate the program with a "Memory fault"
	  (SIGSEGV) error. 

	  Further investigation using the generated core-dump indicates that a
	  call has been made from within fprintf(S) to the memcpy(S) routine,
	  which has been passed a null address argument, e.g.
	  memcpy(0, <s2>, <n>).

	  The following program illustrates this problem:

		#include <stdio.h>

		void main () {
			FILE *fstream;

			if ((fstream=fdopen(1,"w")) == NULL)
			{
				perror("fdopen");
				exit(1);
			}

			fprintf(stdout, "Testing stdout stream\n");
			fprintf(fstream, "Testing fstream file stream\n");
		}

	  This problem is not specific to the use of any of the three standard
	  I/O (stdio) file descriptors 0, 1, and 2 with fdopen(S), but can
	  occur with any valid open file descriptor.

CAUSE:	  This problem is due to the way in which the stdio subsystem 
	  has been implemented in this version of the development system.

	  In the above example program, the fdopen(S) call will create a new
	  file stream data structure called fstream which will contain a
	  reference to file descriptor 1.

	  The initial fprintf(stdout, ...) will then cause an internal buffer
	  to be allocated for use with this stdout stream.

	  The second fprintf(fstream, ...), using the existing file descriptor
	  of 1 to index into the file-buffer table, determines that the file
	  stream fstream already has an allocated buffer for I/O. However, the
	  buffer pointer in the fstream data structure is still unset, i.e.
	  NULL, and so when this address of 0 is then used within the memcpy(S)
	  routine, this results in the program terminating with a segmentation
	  violation (SIGSEGV) signal.

	  The closure of the stdout file stream by fclose(S) following the
	  fprintf(stdout, ...) call or assigning buffering to one of these
	  streams (via setbuf(S) or setvbuf(S)) does not fix this problem.

SOLUTION: This error has been reported to SCO Engineering. This, however,
	  is unlikely to be fixed in the foreseeable future since this problem
	  is fundamental to the stdio architecture in this release of the
	  development system.

	  This problem, however, does not exist in the SCO OpenServer
	  Development System Release 5.0 and so customers are recommended to
	  upgrade to this release of the development system if they are
	  experiencing problems of this nature.

------------------------------------

So, for ODT 5 we can knock out that bit, and consume a few less system
resources. I'll have ODT 5 up one day (its sitting in its box by my side at
this very moment), no doubt it'll need other changes.

Cheers,

Ben.

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant        Fax:   +44 (181) 994 6472
and Technical Director      Email: ben@algroup.co.uk (preferred)
A.L. Digital Ltd,                  benl@fear.demon.co.uk (backup)
London, England.

[Note for the paranoid: "fear" as in "Fear and Loathing
in Las Vegas", "demon" as in Demon Internet Services, a
commercial Internet access provider.]

Mime
View raw message