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.]
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.]