Thanks for the explanation.  Now I see why my program some time crashed at gtk2*.inc...<br><br><div class="gmail_quote">2013/3/14 Martin <span dir="ltr"><<a href="mailto:lazarus@mfriebe.de" target="_blank">lazarus@mfriebe.de</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><div><div class="h5">
    <div>On 14/03/2013 09:47, Jonas Maebe wrote:<br>
    </div>
    <blockquote type="cite"><br>
      <div>
        <div>On 14 Mar 2013, at 01:48, Xiangrong Fang wrote:</div>
        <br>
        <blockquote type="cite"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Monaco;word-spacing:0px"><span style="font-family:monospace">The document said it is
              "deprecated"? Also, I want this to be cross<br>
              platform, not for unix only.  The use case is:<br>
              <br>
              try<br>
               buf := GetMemory(1024);<br>
               size := 10240;<br>
               stream.Read(buf^, size);<br>
              except<br>
               ??<br>
              end;<br>
            </span></span></blockquote>
      </div>
      <br>
      <div>That use case is a textbook example of why you should never
        try to catch and handle access violations, except possibly if
        you then warn the user that anything could happen if he
        continues (including erasing all files on his hard drive, if
        he's very unlucky).</div>
      <div><br>
      </div>
      <div>An access violation often indicates that memory has been
        corrupted. Catching the access violation does not undo the
        memory corruption, it just informs you about this fact. If you
        continue after catching the exception in the above program, you
        will be working with corrupted memory, which means that the
        behaviour of your program becomes completely unpredictable
        afterwards.</div>
      <div><br>
      </div>
    </blockquote></div></div>
    @Xiangrong<br>
    <br>
    In fact (after I saw the screenshot, that indeed the alloc mem is
    less than the read), there is a possibility that the above good does
    NOT even crash. Yet it corrupts memory and the app will crash at a
    random later point.<br>
    <br>
    If the 1024 bytes happen to be allocated in such way that they are
    followed by other already alocated memory, then they can be accessed
    without SigSegV.<br>
  </div>

<br>_______________________________________________<br>
fpc-pascal maillist  -  <a href="mailto:fpc-pascal@lists.freepascal.org">fpc-pascal@lists.freepascal.org</a><br>
<a href="http://lists.freepascal.org/mailman/listinfo/fpc-pascal" target="_blank">http://lists.freepascal.org/mailman/listinfo/fpc-pascal</a><br></blockquote></div><br>