Path: utzoo!utgpu!attcan!ncrcan!hcr!larry From: larry@hcr.UUCP (Larry Philps) Newsgroups: comp.unix.questions Subject: Re: fopen bug in Interactive ix/386 ? Keywords: unix,SYSV,ix/386 Message-ID: <579@hcr.UUCP> Date: 9 May 89 12:56:24 GMT References: <314@edvcom.UUCP> Reply-To: larry@zeus.UUCP (Larry Philps) Organization: HCR Corporation, Toronto Lines: 41 In article <314@edvcom.UUCP> news@edvcom.UUCP writes: > >The following pice of code hangs because it tries to fopen() more than >_NFILE files. Insteed of returning a NULL pointer after the 18th call >it returns a 'valid' descriptor and chrashes. >We are using 1.0.6. >Any suggestions, maybe someone at ico.ISC.COM reading this group ? Actually, there is nothing "wrong" here at all - the file descriptor really is valid. In System V Rel 3, you can configure the number of allowed open file descriptors to be anything between 20 and 100. However in stdio.h you find ... #ifndef _NFILE #define _NFILE 20 ... and in .../lib/libc/port/stdio/data.c you find ... #include ... FILE _iob[_NFILE] = { ... }; Fopen does not keep track of the number of open stdio streams, so when finally fd #20 is returned by the kernel, you start clobbering random data in you program until it crashes. You can fix the behaviour by configuring your kernel to only allow 20 open file descriptors, but this may break other applications that do not use stdio and use lots of fds. The real solution is to fix fopen to malloc a new iob when it runs out of statically allocated ones, and make sure that the stdio macros and routines can access and free these malloced iob's without trouble. If you don't have the source, then you are out of luck. Larry Philps HCR Corporation 130 Bloor St. West, 10th floor Toronto, Ontario. M5S 1N5 (416) 922-1937 {utzoo,utcsri,uunet}!hcr!larry