🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

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

Re: Memory problems: new versus GlobalAlloc

#7027
From: Wim Bekker
Date: Thu, 24 Mar 2005 12:54
105 lines
4984 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: <4242b7d1@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> <4242b6b5@newsgroups.borland.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> <4242b6b5@newsgroups.borland.com>
Subject: Re: Memory problems: new versus GlobalAlloc
Date: Thu, 24 Mar 2005 13:54:28 +0100
Lines: 107
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; Response
NNTP-Posting-Host: 82.161.70.62
Message-ID: <4242b7d1@newsgroups.borland.com>
X-Trace: newsgroups.borland.com 1111668689 82.161.70.62 (24 Mar 2005 04:51:29 -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