This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Mark, re: > I rebuild mcidas 2006 according to your recommendation and it does seem to > have eliminated the problem with strange names for our GRID files. I wish I could tell you that I understand why rebuilding works, but I can't. > The build > went smoothly, there were no errors and all of the tests were successful. We > still have a problem which is likely related. dmgrid.k hangs very frequently > consuming any free cycles on the cpu. It also ceases to process any GRID > data once this happens. We have not been able to get more than one model run > processed before it hangs and more often it does not stay running that long. This is the exact same problem that I referred to in an earlier email. I have not yet been able to deduce what the problem is. One of the problems in troubleshooting this problem is McIDAS programs turn off dumping of core files by default. In order to see where the program is hung, we need a core file. This will require either running dmgrid.k manually from a session in which core dumping is turned on, or modifying the source code to turn the ability to dump a core file back on. > Here is what I'm seeing in XCD_START.LOG: > > --------------------------------------------- > DMMISC Starting: NAMMOS Decoder > DMMISC Starting: GFSMOS Decoder > DMMISC Starting: PIREP/AIREP Decoder > DMMISC Starting: Terminal Forecast Decoder > DMMISC: TIRDEC is labeled inactive: TIROS Navigation Decoder > DMMISC: MDRDEC is labeled inactive: MDR Grid Decoder > Reading /software/mcidas/workdata/RTMODELS.CFG... > ingebin.k: Done > Starting HRS at 06291.164536 > High Resolution Data Service > Program terminated, segmentation violation > DMGRID in free(): warning: junk pointer, too high to make sense > DMGRID in free(): warning: junk pointer, too high to make sense > DMGRID in free(): warning: modified (chunk-) pointer > ------------------------------------------------------------------------- I suspect that there is a pointer that has been incorrectly sized, or there is a product that arrives in the afternoon that is being unpacked incorrectly (the hands I see are always in the afternoon). > We are running FreeBSD 4.10 We are also. When I find the problem (which does not occur on other OSes), I will create an Addendum with the fix. Cheers, Tom **************************************************************************** Unidata User Support UCAR Unidata Program (303) 497-8642 P.O. Box 3000 address@hidden Boulder, CO 80307 ---------------------------------------------------------------------------- Unidata HomePage http://www.unidata.ucar.edu **************************************************************************** Ticket Details =================== Ticket ID: EIJ-330346 Department: Support McIDAS Priority: Normal Status: Open