Path: nntp.gmd.de!xlink.net!howland.reston.ans.net!pipex!sunic!trane.uninett.no!eunet.no!nuug!falcon!hallvard From: hallv...@falcon.no (Hallvard Vassbotn) Newsgroups: comp.lang.pascal Subject: Re: A strange GETMEM behaviour Message-ID: <04NwuAGLBh107h@falcon.no> Date: Wed, 9 Nov 94 09:35:32 GMT References: <39lskm$4t1@axil.datasrv.co.il> Organization: Falcon AS, Oslo, Norway Lines: 45 X-Newsreader: Helldiver 1.07 (Waffle 1.65) In dmurd...@mast.queensu.ca (Duncan Murdoch) writes: >In article <39lskm$...@axil.datasrv.co.il> ga...@zeus.datasrv.co.il (Gal-Or) writes: >>When I have two windows (a main one, and a one that has to save the screen >>before it comes on) everything works fine. The problem begins when I am >>using TWO non-main windows that save their prior screen region. the >>SECOND pointer given to me by the THIRD Vwindow SIMPLY points to the >>MIDDLE OF THE LAST POINTERS AREA ! and it writes over the information >>saved by the second window ! >I'd guess that your Getmem isn't getting as much memory as you thought. Do >you have overflow and range checking turned on? If not, then probably some >calculation of total space has overflowed, and that's why you're having the >problems. Overflow and range checking won't help much for dynamically allocated memory. If you have BP 7.0 try to compile a protected mode version of the code, setting HeapLimit and HeapBlock variables to 0. This will generate a General Protection Fault (RTE 216) if you try to access even one byte off the size of the allocated memory segment. This will make it easer to find your bug. >If that's not it, then I'd guess that you're messing up the heap manager >somehow (writing outside the allocated memory, for instance) and it's getting >confused. >>I have solved this problem by an ugly addition of 4k to each GETMEM >>request. this was it never overwrites memory i already GETMEMed... ! >>Does anyone have a more elegant solution? >I'm reasonably sure that this isn't a Getmem bug, so you should be able to fix >it by tracking down the problem in your own code. Yes. See trick above of how to make it easy to find the bug. You also might want to use the ValidPointer routine that can be found in issue 3 of The Pascal Magazine. This will let you check that a pointer is valid before you use it. -Hallvard Vassbotn. -- / Mr. Hallvard Vassbotn / Falcon AS / hallv...@falcon.no / Pascal Programmer / Stranden 1 / Tel. +47 22831310 / Financial Analysis Systems / N-0250 OSLO, Norway / Fax. +47 22831290 ---=* Is a computer language with goto's totally Wirth-less? *=---