From: cwebb AT ctos DOT com Newsgroups: comp.os.msdos.djgpp Subject: Re: Application crashes Date: Wed, 24 Mar 1999 19:32:57 GMT Message-ID: <36f93c8c.142341@news.weldlink.com> References: <36f3d004 DOT 345356 AT news DOT weldlink DOT com> X-Newsreader: Forte Free Agent 1.11/32.235 Lines: 34 NNTP-Posting-Host: 204.144.249.2 X-Trace: 24 Mar 1999 12:32:52 -0700, 204.144.249.2 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On Tue, 23 Mar 1999 13:42:35 GMT, rd5718 AT irix DOT bris DOT ac DOT uk (Rich Dawe) wrote: > I had many problems trying to trace these seemingly random bugs in >libsocket. The problem is a bug in the socket version of select(), which >is used internally in some of the other socket calls. This bug usually >causes a GPF in VMM, as you say. This bug is fixed in libsocket 0.7.4 beta >2. I'd recommend using that instead as it's a lot more stable. You can >download it from: > Rich, yes I am using select (and sockets) heavily in this app. The bug I was experiencing did go away with the updated library. I did notice several side-effects, however: 1) I had to go through all of the .h files and move the __attribute__((packed)) statements to after each data type within the object (the dox for gxx, IIRC, said that C++ did not support using the packed attribute at the end of the structure. 2) I was using ioctlsocket (after removing the #if 0 from ioctl.h in the djgpp distributions), but its behavior seems to be different now using the libsocket code. This is not really a problem for me, since I find that I don't need non-blocking sockets after all. 3) About 1/3 to 1/2 of the time, the application would lock hard upon exitting -- requiring a power cycle/reset to recover. I can't say that this is a direct effect of the libsocket 0.7.4, although it was a behaviour not previously present. The newer code does seem (other than that last point) to behave much better than the 0.7.3 version. Thank you. -Christopher Webb