Look at Models/Airport/fbo.rgb. OSG under valgrind, chokes on row #52.
entry in the start offset table @0x02D0: 0x2200 entry in the length offset table @0x12D0: 0x0207, means last byte in row at 0x2200+0x0207-1=0x2406 data @0x2200: 0xFE means, copy 0x7E bytes, we got 0x007E pixels. next code @0x227F: 0xFE means, copy 0x7E bytes, we got 0x00FC pixels. next code @0x22FE: 0xFE means, copy 0x7E bytes, we got 0x017A pixels. next code @0x237D: 0xFE means, copy 0x7E bytes, we got 0x01F8 pixels. next code @0x23FC: 0x86 means, copy 0x06 bytes, we got 0x01FE pixels. next code @0x2403: 0x01 means, make 1 copy of next byte, we got 0x01FF pixels. next code @0x2405: 0x01 means, make 1 copy of next byte, we got 0x0200 pixels, scan line complete. next code @0x2407: 0x00 means end of scan line. *BUT* this is already 1 byte outside of the length! It isn't consistent, either. The length for the preceding row #51 includes the terminating zero in the count properly (start offset @02CC: 0x2CCC, length @0x12CC: 0x01EE, last byte according to table: 0x2CCC+0x01EE-1=0x2EB9, terminating zero indeed @0x2EB9) OSG loader notices the completed scan line (but not before attempting to read the next code), so normally no harm is done. The only possibility of a crash would be if the input buffer is at the very end of the heap, so reading the extra byte would result in a segfault. One more reason to convert everything to png, and another couple of hours wasted on an irrelevant bug. Next up are 2 reports in the nasal interpreter, that's gonna be fun :) PS: I don't really understand why the last 2 pixels were not merged into the preceding 6. -- Csaba/Jester ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
