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.
Stonie, The -9 message signals that the end of input has been reached: from $GEMERR/dc.err- -9 ! End of input data file. There are 2 reasons for the decoder to shut down. First is end of input (eg -9), the second is that the timeout without data has been reached (-6). If you are choking on the small bulletins, then its possible that a line length is exceeding the 512 array. I can send this though purify to see if anything is getting stepped on. Steve Chiswell Unidata User Support >From: "Stonie R. Cooper" <address@hidden> >Organization: Planetary Data, Incorporated >Keywords: 200106051947.f55JlSp19757 >Steve, > >In the midst of the code, and have a little more info. > >The long message - the daily report - actually does not seg fault; it gives >me error -9 (a little different than yours) and I just got done tracing it to >the buffer size. > >It's actually the smaller messages that are seg faulting; now that I am >through figuring out the issue on the big one, I'll jump on them - but not a >huge fan of gdb. I'll let you know what I find. > >Stonie > >On Tuesday 05 June 2001 19:33, Unidata Support wrote: >> Stonie, >> >> The 1755Z bulletin you sent is 33312 bytes long. The dcgbul.c buffer is >> 16384 bytes. On my machine, I get a -7 return status for the buffer >> overflow which is expected- but no abnormal segmentation fault. >> >> The key here is that the 1701 and 1802 bulletins are STAHRY hourly >> summaries, while the 1755 is the daily summary STADLY. >> >> If you are choking on all 3 of the bulletins, then the problem is >> probably a line length getting stepped on which might be tripping >> up on optimization that I'm not seeing here. >> >> If it is just the 1755 bulletin, then you cat probably tighten up >> the pattern action to use the /pSTAHRY so that the large daily >> bulletin doesn't go to the decoder. >> >> Let me know if you bomb on all the bulletins, or just the daily, >> or whatever combination. You can recompile the dcstorm decoder >> with the -g flag to get more information from the debugger. >> >> Steve Chiswell >> Unidata User Support >> >> >From: "Stonie R. Cooper" <address@hidden> >> >Organization: Planetary Data, Incorporated >> >Keywords: 200106051851.f55IpJp16157 >> > >> > >> >--------------Boundary-00=_SC0HURQBPXKGR1OS5NQ5 >> >Content-Type: text/plain; >> > charset="iso-8859-1" >> >Content-Transfer-Encoding: 8bit >> > >> >Steve, >> > >> >Thanks! Attached are a few dcstorm message that have come in today . . . >> >I'll start looking, also. >> > >> >Stonie >> > >> >On Tuesday 05 June 2001 18:42, Unidata Support wrote: >> >> >From: "Stonie R. Cooper" <address@hidden> >> >> >Organization: Planetary Data, Incorporated >> >> >Keywords: 200106051810.f55IA3p14466 >> >> > >> >> >Steve, >> >> > >> >> >I hate to bother you - but I was trying to determine the change in >> >> > 5.6.c.1 that broke the dcprof (and others?) for Solaris x86 and Linux. >> >> > I found the reference on the archives - but not the fix. >> >> > >> >> >Also, I noticed the WWUS60 KMKC messages cause dcstorm to seg fault - >> >> >chasing that one down, also. Is it related? >> >> > >> >> >Thanks for any pointers or assistance . . . >> >> >-- >> >> >Stonie R. Cooper, >> >> >Science Officer >> >> >Planetary Data, Incorporated >> >> >3495 Liberty Road >> >> >Villa Rica, Georgia 30180 >> >> >ph. (770) 456-0700; pg. (888) 974-5017; fx. (770) 459-0016 >> >> >> >> Stonie, >> >> >> >> The change in 5.6.C was the creation of a MTLNUX machine type >> >> (where previously we had used MTULTX as a surrogate to identify >> >> the little endian byte flipping). >> >> >> >> The dcprof gbytes.c do_flip routine needs MTLNUX added to the byte flip >> >> check: if((MTMACH == MTULTX)||(MTMACH == MTALPH)|| >> >> (MTMACH == MTVAX)||(MTMACH == MTLNUX)) >> >> >> >> Any problem with dcstorm would be unrelated to the above. I havn't seen >> >> any seg faults here. If you can identify a bulletin that I can reference >> >> that is causing problems, I'll look into it. I just ran though the >> >> bulletins for the last 2 days here under Linux and didn't see any >> >> problems. >> >> >> >> Steve CHiswell >> >> ************************************************************************ >> >>*** * < Unidata User Support UCAR >> >> Unidata Program < (303)497-8644 >> >> P.O. Box 3000 < address@hidden >> >> ------------------------------------------------------------------------ >> >>--- - < Unidata WWW Service >> >> ************************************************************************ >> > >> >-- >> >Stonie R. Cooper, >> >Science Officer >> >Planetary Data, Incorporated >> >3495 Liberty Road >> >Villa Rica, Georgia 30180 >> >ph. (770) 456-0700; pg. (888) 974-5017; fx. (770) 459-0016 >> >> *************************************************************************** >>* < Unidata User Support UCAR Unidata >> Program < (303)497-8644 >> P.O. Box 3000 < address@hidden >> --------------------------------------------------------------------------- >>- < Unidata WWW Service http://www.unidata.ucar.edu/ >> *************************************************************************** > >-- >Stonie R. Cooper, >Science Officer >Planetary Data, Incorporated >3495 Liberty Road >Villa Rica, Georgia 30180 >ph. (770) 456-0700; pg. (888) 974-5017; fx. (770) 459-0016 >