Thanks for the explanation. Now I see why my program some time crashed at gtk2*.inc...
2013/3/14 Martin <laza...@mfriebe.de> > On 14/03/2013 09:47, Jonas Maebe wrote: > > > On 14 Mar 2013, at 01:48, Xiangrong Fang wrote: > > The document said it is "deprecated"? Also, I want this to be cross > platform, not for unix only. The use case is: > > try > buf := GetMemory(1024); > size := 10240; > stream.Read(buf^, size); > except > ?? > end; > > > 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). > > 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. > > @Xiangrong > > 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. > > 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. > > _______________________________________________ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal >
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
