[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20010605: 20010605: 20010605: dcprof in 5.6.c.1.

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
>