Dear David and Randall, Thanks for all your help. I am using the latest OpenDX from CVS on a recent FreeBSD-4.6-PRERELEASE. I found reference to the environment variable "DX_SOCKET_BUFSIZE" in appendix C.1 of the updated user's guide. I've verified that doing a "setenv DX_SOCKET_BUFSIZE 131072" fixes the hang during startup of our huge DX net. For some reason on FreeBSD-4.6-PRERELEASE, even though the kernel sysctl variable "kern.ipc.maxsockbuf" is set to 262144, I can't set DX_SOCKET_BUFSIZE larger than 233016 without dxexec getting an error back from setsockopt() (weird, I'll report this on the FreeBSD mail list). The error message generated is:
"setsockopt: No buffer space available". In any case all is well with our huge net using a value of 131072. Now, even with DX_SOCKET_BUFSIZE set as above I do still experience the "timeout waiting for response from DX" error and core dump from startupui when I start dx with no command line options and then click on "New Visual Program..." in the startupui menu. The core dump occurs while using OpenDX built with the following environment variables set: CFLAGS=-g -D_THREAD_SAFE -I/usr/local/include CXXFLAGS=-g -D_THREAD_SAFE -I/usr/local/include CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib -pthread These are required for proper linking to the multithreaded libGL on FreeBSD using XFree86-4.2.0. If I use "dx -uionly" then I can create and run new nets or open and run existing nets just fine and hardware rendering mode will work. Interestingly, if I build OpenDX without the above variables set then startupui will not crash and I can create and run new or existing nets but only in software rendering mode. I have not yet verified that this still occurs on other platforms with recent OpenDX-CVS but in our experience it does occur with OpenDX-4.1.3 on FreeBSD, Linux, Windows, SGI, and Sun workstations. Tom On Mon, 13 May 2002, David Thompson wrote: > Tom, > > The problem with regards to the hang is already solved in the CVS > tree, but you have to set the environment variable for the SOCKET > size. The problem is a race condition in the socket communication. > With a default socket of 32K, there is a race condition that can > sometimes happen. This is documented in the new docs in the cvs. > > David > > At 1:28 PM -0700 5/10/02, Tom Bartol wrote: > >Also, there is a some bug in dxexec (haven't been able to track it down > >completely yet) which causes it to hang (but only some of the time) on > >server start up when trying to initialize a rather huge net that my > >colleague, Joel Stiles, has written. If you are interested we can point > >you at the net file to see if you might be able to help us track down the > >problem. We'd like to have it fixed before 4.2.0 is released, if > >possible. > > > >Thanks, > > > >Tom > > -- > ............................................................................. > David L. Thompson The University of Montana > mailto:[EMAIL PROTECTED] Computer Science Department > http://www.cs.umt.edu/u/dthompsn Missoula, MT 59812 > Work Phone : (406)257-8530 >
