Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

A strange GETMEM behaviour

70 views
Skip to first unread message

Gal-Or

unread,
Nov 7, 1994, 1:45:42 PM11/7/94
to
I have been expiriencing a strange behaviour of the Getmem function...

I am currently "practicing" Object oriented and I have assigned myself to
a small project of making a totally new object oriented application
framework, such as TV.

I have encountered this problem: I made an object I call VWINDOW which
is similar to the WINDOW Twindow, it is a base upon an application or a
process is being built. If Vwindow is not defined as a main window, it
s constructor asks for space using GETMEM and saves the screen before the
window itself is painted. The destructor, brings the screen back and
FREEMEM's the occupied space.

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 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?

Ronen
ga...@datasrv.co.il

Duncan Murdoch

unread,
Nov 8, 1994, 11:21:51 AM11/8/94
to
In article <39lskm$4...@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.

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.

Duncan Murdoch
dmur...@mast.queensu.ca

Hallvard Vassbotn

unread,
Nov 9, 1994, 4:35:32 AM11/9/94
to
In <dmurdoch.13...@mast.queensu.ca> dmur...@mast.queensu.ca (Duncan Murdoch) writes:
>In article <39lskm$4...@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 / hall...@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? *=---

0 new messages