oldfitdlm not working (opening/reading .fit files) about vtrst3.5 HOT 6 OPEN

Probably later. You might have a chat with Keith in Fairbanks -- he has
played around with re-compiling VTRST3.5.

See you there!

Cheers,
Pasha

On 26/05/2016 12:40 PM, egthomas wrote:

I first ran into this issue several years ago at VT (~2012) and now
again at Dartmouth after making a fresh installation of VTRST3.5 from
github. Calling the IDL routine OldFitOpen on a .fit file results in a
buffer overflow immediately after it loads oldfitdlm, however if you
explicitly use the IDL function and not the DLM then everything works
normally. Similarly, using the IDL routine to open a .fit file and
then trying to use the DLM to read the file (via OldFitRead) fails
with a returned value of -1. Can anyone else replicate this issue?

(for reference I'm running IDL Version 8.4 on Ubuntu 14.04.4 LTS)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#15

Dr Pavlo (Pasha) Ponomarenko

Professional Research Associate
Institute of Space and Atmospheric Studies
University of Saskatchewan

Mailing address:
Physics building
116 Science Place,
Saskatoon, SK, S7N 5E2
CANADA
Phone +1 306 966-6458
Facsimile +1 306 966-6440
Email [email protected]
WWW www.usask.ca/~pasha.ponomarenko

ORCID ID: 0000-0001-8407-0193

 The opposite of skeptic is gullible.

I think it’s much more interesting to live
not knowing, than to have answers which
might be wrong.

Richard Feynman

The object of life is not to be on the side
of the majority, but to escape finding oneself
in the ranks of the insane.

Marcus Aurelius Augustus

from vtrst3.5.

Anyone else have a chance to look at this? I'd like to be able to add .fit compatibility for the IDL gridding without resorting to fittofitacf or circumventing the DLM.

from vtrst3.5.

I honestly dont know enough about IDL and whats happening with the old fit read routines to be able to fix this in a short amount of time.

from vtrst3.5.

I also just noticed this issue and was able to replicate it exactly as Evan describes. I'm running Linux Mint 18 with IDL 8.5.1.

• Emma

from vtrst3.5.

So after browsing through the log files due to the sim_real compilation error in the other thread, it seems like this particular issue is due to the use of 'strncpy' in OldFitIDLtoFitFp and OldFitFitFpToIDL (Lines 53 and 73 of oldfitdlm.c):

In file included from /usr/include/string.h:640:0,
from oldfitdlm.c:14:
In function ‘strncpy’,
inlined from ‘OldFitIDLToFitFp’ at oldfitdlm.c:53:10:
/usr/include/x86_64-linux-gnu/bits/string3.h:120:3: warning: call to __builtin___strncpy_chk will always overflow destination buffer [enabled by default]
return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
^
In function ‘strncpy’,
inlined from ‘OldFitFitFpToIDL’ at oldfitdlm.c:73:10:
/usr/include/x86_64-linux-gnu/bits/string3.h:120:3: warning: call to __builtin___strncpy_chk will always overflow destination buffer [enabled by default]
return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
^

from vtrst3.5.

Changing lines 53 and 73 of rst/codebase/superdarn/src.dlm/oldfitdlm.1.7/oldfitdlm.c from

strncpy(fitfp->date,ifitfp->date,80);

to

strncpy(fitfp->date,ifitfp->date,32); (to match the size of the date value in the oldfitfp structure)

takes care of the buffer overflow issue, but nonsense values still creep into the other parameters in that structure when you actually try using the oldfitread dlm in IDL. So more work is needed to get this functional again.

from vtrst3.5.