20010606: 20010606: dcstorm trace . . .

Stonie,

Just to reinforce this,
If you change any number in $GEMPAK,include, you must do a complete 
"make distclean" and rebuild. All libraries in $GEMLIB with the old size
must be removed.

You may have done this, but I just wanted to restate it otherwise.

Steve Chiswell
Unidata User SUpport



>From: "Stonie R. Cooper" <address@hidden>
>Organization: Planetary Data, Incorporated
>Keywords: 200106062125.f56LPAp08558

>Steve,
>
>Just an FYI . . . the attempt to make the buffer bigger breaks other decoders 
>- namely the dcisig and dcwatch; incidently, I saw no place to make the 
>buffer bigger except in BRIDGE.PRM and bridge.h - at least globally.
>
>I put the globals back to the 16384; it'll be another day, and I'll have to 
>find out why pushing the 65k limit was such a deal for the other decoders.  
>With bulletins easily over 16k, I'll need to search and edit.
>
>Stonie
>
>On Wednesday 06 June 2001 18:57, Unidata Support wrote:
>> Stonie,
>>
>>
>> Add stntbl to the parameter type definition list is dcsels.f, eg:
>>         CHARACTER*(*)   gemfil, prmfil, curtim, stntbl
>>
>> It should be there, but the other compilers are probably not as
>> picky about it. The g77 compiler converting this to C is
>> probably not happy about it being missing. See if that solves your problem.
>>
>> You mentioned you altered the buffer size in dcgbul.f. If you do that,
>> You will have to alter the DCMXBF (BRIDGE.PRM) value accoringly
>> since dcsels.f defines: CHARACTER       bultin*(DCMXBF).
>>
>> Steve Chiswell
>> Unidata User Support
>>
>> >From: "Stonie R. Cooper" <address@hidden>
>> >Organization: Planetary Data, Incorporated
>> >Keywords: 200106061823.f56INVp02428
>> >
>> >Steve,
>> >
>> >Sorry for the babbling updates - but, I've got a few things I wanted to
>> > share and see if any of it stirred thoughts on where to look to deal with
>> > the dcstorm seg fault.
>> >
>> >First - the only decoder that has this problem is dcstorm.  The seg fault
>> >occurs in the dcsels.f code, upon calling DC_FCYL; the app faults
>> > immediately upon entering the call - when I comment out that call, the
>> > app does not seg fault (but of course, doesn't work, either).
>> >
>> >Also, just to see if the file creation was the issue, I made the file for
>> >output with sfcfil, using the sels pack file, and setting it as a ship
>> > file with no stations.
>> >
>> >The seg fault still occurs.
>> >
>> >Interestingly, though, if I set the iflsrc initializer to MFSHIP in
>> > dcsels.f, I don't get a seg fault, but then an error that it can't read
>> > my station file (don't quite get that, as I didn't think MFSHIP needed a
>> > station file).
>> >
>> >I haven't been through the whole list, but MFSF also caused a seg fault -
>> > in the same location as the "2" that iflsrc is set to originally.
>> >
>> >Any thoughts?
>> >--
>> >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
>