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

20010606: dcstorm trace . . .

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
>