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

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

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                        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
>
>