[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20010605: 20010605: 20010605: dcprof in 5.6.c.1.
- Subject: 20010605: 20010605: 20010605: dcprof in 5.6.c.1.
- Date: Tue, 05 Jun 2001 13:52:59 -0600
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
>