I've found similar problems with some Linux versions, most recently with the new RPMS (build date Feb 18 2000 10:00:07 AM PST). Example: running sample pgm. AlternateVisualizations.net usually executes only once. Clicking Execute again, or changing the type (contours, bands, grayscale...) and re-executing dumps core with a seg. fault.
Trying Alan's suggestion below seems to fix the problem. Note that changing the filenames back to (in this case) "cloudwater" or "temperature" instead of "filename.dx" crashes -- therefore it doesn't just appear to be a problem in the format of the visual program. A further complication: this happens **ONLY** with the RPM version and possibly (can't keep track) with the .tar.gz binaries. My home built (CVS 1/28) seems to work OK as does (I think) my build of 4.0.6. The behavior is the same on my two systems, one a Pentium 166/ 64 meg./ 2 meg video (pretty minimal) the other a PII400/128/8. Both are RH6.1, LessTif 89.9, Mesa 3.1-3. I did not separately download the hdf/cdf library stuff so they are probably not in my builds (unless they're now part of the CVS source) Hope this helps localize the problem further. Best regards, Peter (old fashioned organic synthetic chemist ...) Alan Ferrenberg wrote: > Hi All, > > After working with Greg Gabra last week, we managed to eliminate the > dictionary as the source of the memory corruption running samples on IRIX. > I also tried upgrading to IRIX 6.5.7f to get a fix for a Motif library > memory corruption problem, but this didn't solve it either. However, I > think I've finally managed to isolate the problem and would like to toss it > out here to see what you think. > > I made two copies of AutoColor.net and modified them as follows: In one > copy, I specify the full pathname to the watermolecule.dx datafile in the > Import module and in the second, gave "watermolecule.dx". (The original > AutoColor.net only has "watermolecule" in the name field in Import.) Each > of the two copies run perfectly while the original still dumps core when I > try to rotate it! That sure suggests to me that the memory corruption is > actually happening during the data importing process, in particular while > trying to determine the datafile format if it's not specified. The problem > could be in one of the import routines (in src/exec/dxmods) or it could be > with the netcdf, cdf or hdf libraries. > > I'll try rebuilding DX a few times, eliminating a different data format > library each time to see if I can narrow it down some more. Any other > advise, or independent confirmations that this is causing trouble would be > welcome. > > ********************************************************************* > Alan M. Ferrenberg ([EMAIL PROTECTED]) > Manager, Research and Computational Science Support > UGA Computing and Networking Services > > Get the latest information from UCNS! Subscribe to our weekly e-mail > publication "UCNS Weekly News". For more information, check out: > > http://www.uga.edu/ucns/consult/casnews/ > > *********************************************************************
