🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: borland.public.cppbuilder.nativeapi
Article #7026

Re: Memory problems: new versus GlobalAlloc

#7026
From: Wim Bekker
Date: Thu, 24 Mar 2005 12:49
109 lines
4969 bytes
"Bob Gonder" <notbg@notmindspring.invalid> wrote
<snip>
> You never check if new or GlobalAlloc succeed in allocating Buffer.

Ok, so I did that and noticed that GetDIB failes sometimes. I cannot find 
any reason for this failure but I suspect Borlands memory manager or page 
swapping is the problem.

The program adds a TMemoryStream with a JPEG image to a THeapList.
In the main thread I check for an object and render it to screen.
In this method, I checked the HeapStatus.

Looking at the results below I cannot understand why there is sometimes a 
difference between begin and end. It looks like the memory manager doesn't 
free the memory block or doesn't re-use it or so. I've noticed that Borland 
uses VirtualAlloc and VirtualFree. Both allocate page swapable memory.


Here are the results. Half way the method, I allocate memory for the buffer.
Just before the error occurs, there's a difference between end and begin. 
Result (the difference) show some values, where I should think they should 
all be zero.

(best viewed with a fixed font)

      TotalAddrSpace  TotalUncommitted  TotalCommitted

begin       1.048.576    950.272     98.304
size=921600 2.097.152  1.064.960  1.032.192
end         1.048.576    950.272     98.304
result              0          0          0

begin       1.048.576    966.656     81.920
size=921600 1.048.576     32.768  1.015.808
end         1.048.576    966.656     81.920
result              0          0          0

begin       1.048.576    966.656     81.920
size=921600 1.048.576     16.384  1.032.192
end         1.048.576    966.656     81.920
result              0          0          0

begin       1.048.576    950.272     98.304
size=921600 2.097.152  1.048.576  1.048.576
end         1.048.576    933.888    114.688
result              0    -16.384     16.384

begin       1.048.576    933.888    114.688
size=921600 2.097.152  1.032.192  1.064.960
end         1.048.576    933.888    114.688
result              0          0          0

begin       1.048.576    933.888    114.688
size=921600 2.097.152  1.032.192  1.064.960
end         2.097.152  1.966.080    131.072
result      1.048.576  1.032.192     16.384        Not zero, the next time 
an error

begin       2.097.152  1.966.080    131.072
size=921600 3.145.728  2.064.384  1.081.344
(0) Result=0 Access denied. (this doesn't make sense and sometimes I get a 
message not enough memory)
end         2.097.152  1.966.080    131.072
result              0          0          0



If I add a TImage to the form and do
Image1->Picture->Assign(Bitmap);
just before deleting the buffer, the error occurs almost direct:

begin       1.048.576    999.424     49.152
size=921600 1.048.576     49.152    999.424
end         1.048.576    983.040     65.536
result              0    -16.384     16.384    Not zero, but this is the 
very first time, no error

begin       1.048.576    983.040     65.536
size=921600 2.097.152  1.081.344  1.015.808
end         2.097.152  2.015.232     81.920
result      1.048.576  1.032.192     16.384    Not zero, the next time an 
error

begin       2.097.152  2.015.232     81.920
size=921600 3.145.728  2.113.536  1.032.192
(0) Result=0 Access denied.
end         3.145.728  3.063.808     81.920
result      1.048.576  1.048.576          0

begin       3.145.728  3.063.808     81.920
size=921600 3.145.728  2.113.536  1.032.192
end         2.097.152  2.031.616     65.536
result     -1.048.576 -1.032.192    -16.384

begin       2.097.152  2.031.616     65.536
size=921600 2.097.152  1.081.344  1.015.808
end         2.097.152  2.015.232     81.920
result              0    -16.384     16.384

begin       2.097.152  2.015.232     81.920
size=921600 3.145.728  2.113.536  1.032.192
(1) Result=0 Access denied.
end         3.145.728  3.047.424     98.304
result      1.048.576  1.032.192     16.384



 
Technical Details
Message-ID: <4242b6b5@newsgroups.borland.com>
Path: arc1-ca.pugleaf.net!g2news1.google.com!news4.google.com!news.glorb.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsgroups.borland.com!not-for-mail
References: <42403f3c@newsgroups.borland.com> <42408062$3@newsgroups.borland.com> <42413c01$1@newsgroups.borland.com> <ca9441lbia8eochgsn5f6bltpsjamjf983@4ax.com>

Show Full Headers
Complete Article Headers
X-Google-Thread: 10cc67,6b3a605b9bc38024
X-Google-Attributes: gid10cc67,public
X-Google-Language: ENGLISH,ASCII-7-bit
From: "Wim Bekker" <no-no-no-mail@no-no-noware.com>
Newsgroups: borland.public.cppbuilder.nativeapi
References: <42403f3c@newsgroups.borland.com> <42408062$3@newsgroups.borland.com> <42413c01$1@newsgroups.borland.com> <ca9441lbia8eochgsn5f6bltpsjamjf983@4ax.com>
Subject: Re: Memory problems: new versus GlobalAlloc
Date: Thu, 24 Mar 2005 13:49:43 +0100
Lines: 111
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Original
NNTP-Posting-Host: 82.161.70.62
Message-ID: <4242b6b5@newsgroups.borland.com>
X-Trace: newsgroups.borland.com 1111668405 82.161.70.62 (24 Mar 2005 04:46:45 -0800)
Path: arc1-ca.pugleaf.net!g2news1.google.com!news4.google.com!news.glorb.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsgroups.borland.com!not-for-mail