Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Eric Grange

Delphi 5 Compiler Bug Alert

This topic is 6389 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've found a flaw in the Delphi Compiler (could possibly be in BCB too... can someone check?), it has been confirmed by Steffan Hoffmeister and the test code is below. It is particularly relevant for the graphics/game programming, especially is you use *byte* access to bitmaps, maps or whatever byte-based structures. The following code showcases a compiler bug in which a *BYTE* read access is effectively performed via a *DWORD* read access (through a stack push), resulting in the possible read of unallocated bytes, which can trigger a non-trivial access violation (f.i. a bitmap's ScanLine). The test code is a "minimal" case, but the problem seems to be rooted somewhat more deeply in the register allocation, and I originally bumped on it with byte pointer parameter passing... The workaround is included in the test code (using a local, intermediate variable). *********************** The following is the exploit, enhanced by Steffan Hoffmeister to feature a big access violation:
  
{$A+,B-,C+,D+,E-,F-,G+,H+,I+,J+,K-,L+,M-,N+,O+,P+,Q-,R-,S-,T-,U-,V+,W-,

X+,Y+,Z1}
{$MINSTACKSIZE $00004000}
{$MAXSTACKSIZE $00100000}
{$IMAGEBASE $00400000}

{$APPTYPE CONSOLE}

program Project1;

{$O+}

uses
  Windows,
  SysUtils;

type
  TByteArray = array [0..15] of Byte;
  PByteArray = ^TByteArray;

function AllocateMemory: PByteArray;
const
  AllocGranularity = 64 * 1024;
var
  NextPage: Pointer;
begin
  // We'll leak all memory allocated here.


  // Allocate two consecutive pages of memory;

  // the second page will get NOACCESS, and the

  // returned memory address will be adjusted so

  // that it ends right before the NOACCESS page


  Result := VirtualAlloc(nil, AllocGranularity, MEM_COMMIT,
PAGE_READWRITE);
  if Result = nil then
    RaiseLastWin32Error;

  Inc(Cardinal(Result), AllocGranularity);

  NextPage := VirtualAlloc(Result, AllocGranularity, MEM_RESERVE,
PAGE_NOACCESS);
  if NextPage = nil then
    RaiseLastWin32Error;

  Assert(NextPage = Result);

  Dec(Cardinal(Result), SizeOf(Result^));
end;

var
  i, start, mask: Integer;
  //src, dest : TByteArray;

  pSrc, pDest: PByteArray;
  b: Byte;
begin
  start := 0;
  mask := 255;

  pSrc := AllocateMemory;
  pDest := AllocateMemory;

  // Our memory allocation code works fine...

  pSrc[High(TByteArray)] := 0;
  pDest[High(TByteArray)] := 0;

  pSrc[Low(TByteArray)] := 0;
  pDest[Low(TByteArray)] := 0;

  // Compiled incorrectly: bytes are accessed through

  // 32 bit access, effectively reading beyond array length,

  // possibly causing a crash if that memory cannot be read.

  for i := 0 to 15 do
    pSrc[i-start] := pDest[i and mask];

  // This one is compiled correctly.

  for i := 0 to 15 do
  begin
    b := pDest[i and mask];
    pSrc[i-start] := b;
  end;
end.    
  
--- Eric Grange http://glscene.org Edited by - Eric Grange on February 19, 2001 4:15:37 AM

Share this post


Link to post
Share on other sites
Advertisement
Hi Erik,
Has this bug been reported to at least David Intersimone ( dintersimone@borland.com ) and John Kaster ( jkaster@borland.com ) or anyone else at Borland?
If not I would suggest that your post be forwarded to them so bring he issue to light. Also please post any responses they make back to the community forum, so that The community can keep track of how this porblem is being handled.
Make sure you mention how urgent this fix is required;-).


Sincerely,


Dom.
http://www.savagesoftware.com.au/delphi/



Edited by - savage on February 20, 2001 8:55:56 AM

Share this post


Link to post
Share on other sites
Thanks for the emails Dom, I''ve just sent the report.

Btw, I originally posted in borland.delphi.non-technical, but no one gave me a link nor email
Turbo forum is better


---
Eric Grange
http://glscene.org

Share this post


Link to post
Share on other sites
The saga continues: John Kaster told me they (he and D.I) weren''t the people to report to, but that I should post to borland.delphi.objectpascal... so here it went.

BTW, I thought Borland wasn''t actually monitoring the NG, only TeamB was... would mean there is no "official" channel???


---
Eric Grange
http://glscene.org

Share this post


Link to post
Share on other sites
Here is the note I got from Rudy Velthuis (TeamB):

>As of today, the interim bug report page is:
>
>http://pso.inprise.com/webcustomer/clearexx_cgi/x_Site_Open_Bug.htm
>
>Yes, that is the old bug report page, with a warning on top. You''ll only
>get an auto-reply **for now**.

Hehe... if you don''t know it, you can''t guess it...
I''m forwarding the link to the Delphi Bug list admin.

---
Eric Grange
http://glscene.org

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!