I'm running release tests and worryingly, an HDS file (v3) created in
January for ACSIS commissioning is causing core dumps in HDS.
This occurred initially in wcsattrib but it turns out that that was just
the messenger and simply calling
hdelete testfile.WCS
causes the segv (since wcsattrib does that before it writes the new WCS).
I think there is a corruption in the file structure somewhere but I don't
know enough to know when there is a problem.
valgrind indicates that the problem is starting in rec1_deall_frame
and is caused by the for loops going negative because there is no check
for the loop condition to end (it relies on some condition happening
inside the loop causing a break rather than the loop itself stopping on
its own when the array index hits 0).
In the debugger I get the problem with this HCB:
$2 = {
stk = {{
bloc = 103957,
spare = 98832
}, {
bloc = 68246,
spare = 615490
}, {
bloc = 663553,
spare = 137575
}, {
bloc = 235028,
spare = 94736
}, {
bloc = 67990,
spare = 614754
}, {
bloc = 1,
spare = 0
}, {
bloc = 0,
spare = 0
} <repeats 90 times>},
eof = 38521,
stamp = 5456979,
version = 3
}
and this never meets the loop end condition since stk[i].bloc is never -1
and it never equals (bloc + size) [38491+15] (this seems to be confirmed
when doing an hdsdump on the file but I don't know enough of hdsdump's
output to work out why there is a problem in general - bloc 38491 seems to
be:
Primitive record (38419,5):
Parent(b=38419,c=1),size=1,chained=1,active=1,slen=20,dlen=7520
Chained data starts block = 38491 size(blocks)=15
Packed dype = _CHAR length=32, naxes=1 (235 )
Test file can be downloaded from
http://www.jach.hawaii.edu/~timj/breaks2.sdf.gz
I'm hoping that this is a one off rather than a general trend, but can
people try things out (I realise that almost everyone is on holiday). I've
tried with a current HDS and one from back in May, and rec1_deall_frame
itself has not been modified in a long time. Since this is the only file
that I can find causing the problem I'm not going to hold the release (but
please let me know if others are found)
It would seem that at least rec1_deall_frame.c should have a backup
condition check to stop it addressing random memory.
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|