Subject: Re: Abi crashers
From: Robert Wilhelm (robert@gaston.camelot.de)
Date: Thu Dec 27 2001 - 15:23:21 CST
Hi!
I had a look at following document:
Zusammenfassung der Projektwoche.doc
Following happens:
wvEatOldGraphicHeader goes through METAFILE data scanning for entries
with bitmaps.
It finds some sort of end entry "suspect we are finished", but as
there are still two bytes left ( probably for padding) it still goes on
reading METAFILE entries, despite they should be at least 6 bytes
(4 Bytes lenght, 2 Bytes id).
Appended patch fixes this bug, but I am not sure this is the best
solutions. Maybe we should just stop when reading an end entry or
we should demand that at least 6 more byte must be available.
Any pointer to dokumentation of this part of word file format
is welcome, as all what I got ("wword60.txt") is a bit sparse.
Trace: (support.c:130) read_16ubit
Trace: (picf.c:172) Entry is 4, 167be, count is 85552
Trace: (picf.c:188) len is 2, predict end of 167c2
Trace: (support.c:130) read_16ubit
Trace: (support.c:130) read_16ubit
Trace: (picf.c:172) Entry is 4, 167c6, count is 85560
Trace: (picf.c:188) len is 2, predict end of 167ca
Trace: (support.c:130) read_16ubit
Trace: (support.c:130) read_16ubit
Trace: (picf.c:172) Entry is 3, 167ce, count is 85568
Trace: (support.c:130) read_16ubit
Trace: (picf.c:180) suspect that we are finished, count 85570, len 85572
Trace: (picf.c:172) Entry is 4c40000, 167d4, count is 85574
Trace: (picf.c:188) len is 79953918, predict end of 98967d0
Trace: (support.c:130) read_16ubit
Trace: (support.c:130) read_16ubit
--- picf.c.org Fri Dec 21 22:05:56 2001
+++ picf.c Thu Dec 27 00:53:59 2001
@@ -235,7 +239,7 @@ wvEatOldGraphicHeader (wvStream * fd, U3
break;
}
}
- while (count + 1 < len);
+ while (count + 2 < len);
wvTrace (("Entry is %x %x, %d\n", entry, wvStream_tell (fd), count));
return (count);
}
This archive was generated by hypermail 2b25 : Thu Dec 27 2001 - 15:26:36 CST