Brian,
I think I'm getting the hang of it. The code in the fortran interface is
the culprit since it relies on HDS_PTYPE == F77_INTEGER_TYPE.
The comment in hds1.h concerning changing the file format if HDS_PTYPE
is set to long long worries me a bit since it implies that if I create a
file with HDS_PTYPE == long long that it won't be readable on the same
computer where HDS was compiled with HDS_PTYPE == int.
If that is true then HDS_PTYPE is extremely dangerous. Does HDS spot the
problem? Does the file format say whether HDS_PTYPE is 8 bytes or 4 so
that it can convert?
Can a new format file be read on a system that does not have an 8 byte
INT_BIG? (but is compiled with the current codebase) Or does this switch
to HDS64 mean that we are now locked into 8 byte integers? Currently the
test for INT_BIG == long long does not allow for a 'long long' being
unavailable. Should the compiler switch to 4 byte long for INT_BIG or
should it refuse to compile because it won't be able to read the files
anyway?
I've had a go at building with HDS_64 defined. It fixes the signedness
problem since HDS_64 seems to be entirely designed for the case where
sizeof(HDS_PTYPE) != sizeof(Fortran int). Once I'd fixed a problem in the
fortran interface (dat_shape was not getting it's return values) I've now
got hds_test.f core dumping when it annuls the first HDS locator.
#0 0x00a92d40 in dat1_cvt_dtype (bad=-1207970304, nval=200,
imp=0x8de8908, exp=0x0,
nbad=0xbfebe874) at daucnv.c:183
183 des[n] = (_INTEGER) src[n]; /* Overflow? */
#1 0x00a96bb4 in dat1_cvt (bad=1, nval=200, imp=0x8de6d7c, exp=0x8de6d88,
nbad=0xbfebe874)
at dautypes.c:148
#2 0x00a95085 in dau_flush_data (data=0x8de6d40) at dauflush.c:109
#3 0x00a8f551 in datUnmap (locator_str=0xb7ffd600 "", status=0xbfebe92c)
at datmap.c:532
#4 0x00aa3631 in dat_unmap_ (locator=0xbfebe930
"8mb\177\177\177\177\002",
status=0xbfebe92c, locator_length=15) at fortran_interface.c:1905
#5 0x08048a58 in MAIN__ () at hds_test.f:83
I'm assuming the problem is that exp is a null pointer on entry and
daucnv.c does not check for this error condition. 'exp' is defined in the
routine above but not by the time it is passed to dat1_cvt_dtype. This is
well out of my depth though.
So to summarise:
* Must HDS_PTYPE be identical on all systems that use HDS64 for the
files to interoperate?
* Should HDS_PTYPE always be a fortran int?
I hope you have time to answer my worries.
Tim
On Wed, 7 Sep 2005, Tim Jenness wrote:
> Okay. The problem seems to be in HDS_PTYPE. Since it was a dimension I made
> it unsigned rather than signed but that has caused big problems.
>
> Brian: any comment?
>
> I don't know why but I'll revert that change in CVS and then try to see if
> it's an obvious problem with the fortran interface somewhere (which has a
> signed/unsisgned issue).
>
> Tim
>
> On Wed, 7 Sep 2005, Tim Jenness wrote:
>
>>
>> Warning: I think HDS (HDS64 after merge and tweaks) broke in the past few
>> days. I haven't worked out when but if I do an fits2ndf on
>>
>> http://www.jach.hawaii.edu/~timj/c18o.fit
>>
>> I get a file that is listed as 137439196672 bytes. It really did take up
>> that much disk space but a reboot and jorunal fix listed the file as 245760
>> bytes (the correct size) but still took up 137MB until it was rm'ed.
>>
>> I'm going to have to try to rebuild HDS from the past few days to work out
>> exactly when it broke.
>>
>>
>
>
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
