Access Violation In Walking Memory

[Glenn9999]

I have a problem that's starting to get me frustrated. To simplify what I'm doing, I'm walking a contiguous block of memory and using a pointer along with some retyping to access the contents. The data are variable, so that's why I'm doing this.

Anyway to simplify the logic (to remove some code that acts on these variables):

currp := memrec;
datasize := size_decode(THeader(currp^).size) - 1;
repeat
  incptr(currp, sizeof(THeader));
  [b]move(currp^, outrec.title, datasize);[/b]
  incptr(currp, datasize);
  datasize := size_decode(THeader(currp^).size) - 1;
until datasize < 0;

The access violation occurs only sometimes on the line in bold. Right now, incptr just adds datasize to the pointer value. My first thought is that somehow what I'm doing to increment the pointer is corrupting the address so it's not quite right.

Size_decode might possibly be an issue, since there are some wierd rules on how the datasize value is represented, but the code works in about 80% of the other cases I've tried.

Any ideas on this one to solve it?

Measurement is not management.

 

[whosrdaddy]

one guess is that, sometimes datasize is larger than your outrec.title structure can hold (is that a string??)

stepping through the code (or add logging) might give more insight.

/Daddy

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[Glenn9999]

I think I got this one figured out (finally!). It turns out that the code I have to determine the size of the data block was wrong. Or more accurately, incomplete.

Actually, I could use an extra set of eyes or two on this one. I got it so it basically works now. I need to test the last data block, though. But I could have something wrong somewhere.

This obviously needs cleaned up in numerous ways, but is there anything wrong with it logically? It's purpose is to decode a MSB DWord value where bit 7 of each byte is not used.

type
  sarray = array[0..3] of byte;

function size_decodeh(insize: sarray): DWord;
    var
      outdval: DWord;
      outd: psarray;
      tnext1, tnext2: byte;
      pnext1, pnext2: byte;
      cnext1, cnext2: byte;
    begin
      outdval := 0;
      outd := @outdval;
   // first pass
      tnext1 := insize[3] or ((insize[2] and $01) shl 7);
      tnext2 := insize[2] shr 1;
   // second pass
      pnext1 := tnext2 or ((insize[1] and $03) shl 6);
      pnext2 := insize[1] shr 2;
   // third pass
      cnext1 := pnext2 or ((insize[0] and $07) shl 5);
      cnext2 := insize[0] shr 3;
      outd^[0] := tnext1;
      outd^[1] := pnext1;
      outd^[2] := cnext1;
      outd^[3] := cnext2;
      Result := outdval;
    end;

any thoughts?

Measurement is not management.

 

[roo0047]

Glenn - I was going to make the same comment as daddy on datasize.

I had the same problem reading a proprietary data stream into a predefined record structure. My solution was to do a fillchar(x, n, #0) on the destination buffer and added an extra 1 or 4 byte to the destination size. The parse routine searched for end-of-field byte-flags and end-of-record flags or #0. It solved my problem, but never figured out why.

Roo
Delphi Rules!

 

[DjangMan]

Could it be how the fields are aligning themselves to word boundaries in memory? By adding extra bytes you guarantee yourself that you're going over to the next boundary.

Similar to the difference between a record and a packed record. The packed record doesn't align the variables on word boundaries.