Memory error in OpenGL-es 2.0 code - memory

I have written a code in OpenGL-ES 2.0 with PVRSDK in Ubuntu 10.10 , now the thing is that whatever output I want , I am getting that but it comes and then the window disappears ,
If I put a break-point I am getting what I want. But I don't understand why the window disappears .
When I do the memory check with valgrind I got these errors :
==5997== Memcheck, a memory error detector
==5997== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==5997== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==5997== Command: ./cube
==5997==
libEGL warning: use software fallback
==5997==
==5997== HEAP SUMMARY:
==5997== in use at exit: 12,126 bytes in 94 blocks
==5997== total heap usage: 97,499 allocs, 97,405 frees, 197,353,970 bytes allocated
==5997==
==5997== 8 bytes in 1 blocks are definitely lost in loss record 3 of 57
==5997== at 0x4024F12: calloc (vg_replace_malloc.c:467)
==5997== by 0x486CE90: __glXInitialize (glxinit.c:584)
==5997== by 0x486AA61: x11_screen_support (x11_screen.c:133)
==5997== by 0x486DEEB: x11_create_dri2_display (native_dri2.c:700)
==5997== by 0x4869AEA: native_create_display (native_x11.c:42)
==5997== by 0x4866A2A: egl_g3d_initialize (egl_g3d.c:498)
==5997== by 0x4176F36: _eglMatchDriver (egldriver.c:580)
==5997== by 0x4170BBF: eglInitialize (eglapi.c:294)
==5997== by 0x8049EFF: main (Hello.cpp:231)
==5997==
==5997== 40 bytes in 1 blocks are definitely lost in loss record 31 of 57
==5997== at 0x4026351: operator new(unsigned int) (vg_replace_malloc.c:255)
==5997== by 0x8049CE3: main (Hello.cpp:206)
==5997==
==5997== 72 bytes in 1 blocks are definitely lost in loss record 34 of 57
==5997== at 0x4024F12: calloc (vg_replace_malloc.c:467)
==5997== by 0x4A50C7C: st_bufferobj_alloc (st_cb_bufferobjects.c:56)
==5997== by 0x49A1B78: _mesa_alloc_shared_state (shared.c:94)
==5997== by 0x498860F: _mesa_initialize_context_for_api (context.c:904)
==5997== by 0x49886DB: _mesa_create_context_for_api (context.c:1050)
==5997== by 0x49C7479: st_create_context (st_context.c:176)
==5997== by 0x4985A80: st_api_create_context (st_manager.c:646)
==5997== by 0x4868843: egl_g3d_create_context (egl_g3d_api.c:131)
==5997== by 0x4173127: eglCreateContext (eglapi.c:413)
==5997== by 0x804A039: main (Hello.cpp:261)
==5997==
==5997== 1,546 (48 direct, 1,498 indirect) bytes in 1 blocks are definitely lost in loss record 55 of 57
==5997== at 0x4025BD3: malloc (vg_replace_malloc.c:236)
==5997== by 0x4BABD13: talloc_enable_null_tracking (in /usr/lib/libtalloc.so.2.0.1)
==5997== by 0x4BABE28: talloc_init (in /usr/lib/libtalloc.so.2.0.1)
==5997== by 0x49F48B5: glsl_symbol_table::glsl_symbol_table() (glsl_symbol_table.cpp:60)
==5997== by 0x49F2566: _mesa_glsl_parse_state::_mesa_glsl_parse_state(__GLcontextRec*, unsigned int, void*) (glsl_parser_extras.cpp:50)
==5997== by 0x49D68B3: _mesa_glsl_compile_shader (ir_to_mesa.cpp:2815)
==5997== by 0x49A0486: _mesa_CompileShaderARB (shaderapi.c:807)
==5997== by 0x804A0E1: main (Hello.cpp:280)
==5997==
==5997== LEAK SUMMARY:
==5997== definitely lost: 168 bytes in 4 blocks
==5997== indirectly lost: 1,498 bytes in 28 blocks
==5997== possibly lost: 0 bytes in 0 blocks
==5997== still reachable: 10,460 bytes in 62 blocks
==5997== suppressed: 0 bytes in 0 blocks
==5997== Reachable blocks (those to which a pointer was found) are not shown.
==5997== To see them, rerun with: --leak-check=full --show-reachable=yes
==5997==
==5997== For counts of detected and suppressed errors, rerun with: -v
==5997== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 54 from 11)
Now those lines which they are mentioning :
206 x11Visual = new XVisualInfo;
207 XMatchVisualInfo( x11Display, x11Screen, i32Depth, TrueColor, x11Vis ual);
208 if (!x11Visual)
209 {
210 printf("Error: Unable to acquire visual\n");
211 goto cleanup;
212 }
===========================================================================================
230 EGLint iMajorVersion, iMinorVersion;
231 if (!eglInitialize(eglDisplay, &iMajorVersion, &iMinorVersion))
232 {
233 printf("Error: eglInitialize() failed.\n");
234 }
==========================================================================================
eglContext = eglCreateContext(eglDisplay, eglConfig, NULL, ai32Conte xtAttribs);
262 if (!TestEGLError("eglCreateContext"))
263 {
264 goto cleanup;
265 }
============================================================================================
279 glShaderSource(uiFragShader, 1, (const char**)&pszFragShader, NULL);
280 glCompileShader(uiFragShader);
So I just want to know that its because of these errors I am getting that screen disappears or something else might be the reason .

I just want to know that its because of these errors I am getting that screen disappears or something else might be the reason
The latter. Leaks do not affect program runtime (unless they are so large that the program fails to allocate more memory when it needs it; but your leaks are small).
Did you forget to enter the X event loop?
Update:
int i32NumMessages = XPending( x11Display );
for( int i = 0; i < i32NumMessages; i++ )
{
XEvent event;
XNextEvent( x11Display, &event );
}
That loop is in fact
obviously wrong
the reason your application (almost) immediately exits
You are processing only the events queued so far (which is likely a very small number of events). And you are actually discarding them. You'll probably want to write something like this instead.

Related

Memory Leak inspection with Windbg - Increase in heap size doesn't reflect in Heap detail

I'm trying to detect a memory leak location for a certain process via Windbg, and have come across a strange problem.
Using windbg, I've created 2 memory dump snapshots - one before and one after the leak, that showed an increase of around 20MBs (detected via Performance Monitor - private bytes). it shows that there is indeed a similar size difference in one of the heaps before and after the leak (Used with the command !heap -s):
Before:
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-----------------------------------------------------------------------------
03940000 08000002 48740 35312 48740 4372 553 9 5 2d LFH
External fragmentation 12 % (553 free blocks)
03fb0000 08001002 7216 3596 7216 1286 75 4 8 0 LFH
External fragmentation 35 % (75 free blocks)
05850000 08001002 60 16 60 5 2 1 0 0
...
After:
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-----------------------------------------------------------------------------
03940000 08000002 64928 55120 64928 6232 1051 26 5 51 LFH
External fragmentation 11 % (1051 free blocks)
03fb0000 08001002 7216 3596 7216 1236 73 4 8 0 LFH
External fragmentation 34 % (73 free blocks)
05850000 08001002 60 16 60 5 2 1 0 0
...
See the first Heap (03940000) - there is a difference in committed KBs of around 55120 - 35312 = 19808 KB = 20.2 MB.
However, when I inspected that heap with (!heap -stat -h 03940000), it displays the following for both dump files:
size #blocks total ( %) (percent of total busy bytes)
3b32 1 - 3b32 (30.94)
1d34 1 - 1d34 (15.27)
880 1 - 880 (4.44)
558 1 - 558 (2.79)
220 1 - 220 (1.11)
200 2 - 400 (2.09)
158 1 - 158 (0.70)
140 2 - 280 (1.31)
...(rest of the lines show no difference)
size #blocks total ( %) (percent of total busy bytes)
3b32 1 - 3b32 (30.95)
1d34 1 - 1d34 (15.27)
880 1 - 880 (4.44)
558 1 - 558 (2.79)
220 1 - 220 (1.11)
200 2 - 400 (2.09)
158 1 - 158 (0.70)
140 2 - 280 (1.31)
...(rest of the lines show no difference)
As you can see, there is hardly a difference between the two, despite the abovementioned 20MB size difference.
Is there an explanation for that?
Note: I have also inspected the Unmanaged memory using UMDH - there wasn't a noticeable size difference there.

Why do I get memory leak?

Consider the following piece of code:
#include
#include
int main () {
char *str;
/* Initial memory allocation */
str = (char *) malloc(15);
strcpy(str, "tutorialspoint");
printf("String = %s, Address = %u\n", str, str);
str = NULL;
free(str);
return(0);
}
Why does the above program cause a memory leak? How do I avoid this?
An error is thought to occur in "str = NULL;". Why?
valgrind log:
==4143== Memcheck, a memory error detector
==4143== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==4143== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==4143== Command: ./a.out
==4143==
String = tutorialspoint, Address = 86097984
==4143==
==4143== HEAP SUMMARY:
==4143== in use at exit: 15 bytes in 1 blocks
==4143== total heap usage: 2 allocs, 1 frees, 1,039 bytes allocated
==4143==
==4143== 15 bytes in 1 blocks are definitely lost in loss record 1 of 1
==4143== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4143== by 0x1086EB: main (in /home/stack/a.out)
==4143==
==4143== LEAK SUMMARY:
==4143== definitely lost: 15 bytes in 1 blocks
==4143== indirectly lost: 0 bytes in 0 blocks
==4143== possibly lost: 0 bytes in 0 blocks
==4143== still reachable: 0 bytes in 0 blocks
==4143== suppressed: 0 bytes in 0 blocks
==4143==
==4143== For counts of detected and suppressed errors, rerun with: -v
==4143== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
free(str); frees the space pointed to by str, where str is the space obtained by malloc. Because of the line str = NULL; happens before the free, free is attempting to deallocate the memory position at location 0. By definition in the C standard, this does nothing. It is common to set a pointer to 0 after it is deleted, so that if one were to accidentally attempt to delete it again, nothing happens.
To fix you code, you simply need to swap the lines str = NULL; and free(str);

Memory leakage while releasing Mat in opencv

I have a global variable cv::Mat imageInputRGBA which I want to release it at the end of my program in a clean up function. But I receive a memory leakage message like below from Valgrind. Could anyone please give me any advice how can I can free the the Mat memory correctly without memory leakage?:
==4499== Memcheck, a memory error detector
==4499== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==4499== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==4499== Command: ./nwcc7 im2.png im6.png
==4499==
==4499==
==4499== HEAP SUMMARY:
==4499== in use at exit: 6,086 bytes in 3 blocks
==4499== total heap usage: 412 allocs, 409 frees, 25,693,438 bytes allocated
==4499==
==4499== 30 bytes in 1 blocks are still reachable in loss record 1 of 3
==4499== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4499== by 0x5D64679: strdup (strdup.c:42)
==4499== by 0x698D59E: ??? (in /usr/lib/nvidia-331-updates/libGL.so.331.38)
==4499== by 0x6578652F3938: ???
==4499==
==4499== 32 bytes in 1 blocks are still reachable in loss record 2 of 3
==4499== at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4499== by 0x60A268F: _dlerror_run (dlerror.c:141)
==4499== by 0x60A2197: dlsym (dlsym.c:70)
==4499== by 0x698B8BD: ??? (in /usr/lib/nvidia-331-updates/libGL.so.331.38)
==4499== by 0x6BCD5BF: ??? (in /usr/lib/nvidia-331-updates/libGL.so.331.38)
==4499== by 0x6C00A5F: ???
==4499== by 0x69B12CA: ??? (in /usr/lib/nvidia-331-updates/libGL.so.331.38)
==4499==
==4499== 6,024 bytes in 1 blocks are definitely lost in loss record 3 of 3
==4499== at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4499== by 0x69A427E: ??? (in /usr/lib/nvidia-331-updates/libGL.so.331.38)
==4499==
==4499== LEAK SUMMARY:
==4499== definitely lost: 6,024 bytes in 1 blocks
==4499== indirectly lost: 0 bytes in 0 blocks
==4499== possibly lost: 0 bytes in 0 blocks
==4499== still reachable: 62 bytes in 2 blocks
==4499== suppressed: 0 bytes in 0 blocks
==4499==
==4499== For counts of detected and suppressed errors, rerun with: -v
==4499== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
//--------------------------------------
The code is something like this:
cv::Mat imageInputRGBA;
void CPU_cleanUp(){
imageInputRGBA.release();
}
int main(int argc, char **argv) {
CPU_Part(argc,argv);// I didn't use imageInputRGBA in CPU_Part
CPU_cleanUp();
return 0;
}

VM Tracker shows large Dirty Size

There is a part of my app where I perform operations concurrently. They consist of initializing many CALayers and rendering them to bitmaps.
Unfortunately, during these operations (each takes about 2 seconds to complete on an iphone 4), the Dirty Size indicated by VM Tracker spikes to ~120MB. Allocations spike to ~12MB(does not accumulate) From my understanding, the Dirty size is memory that cannot be freed. so often, my app and all other apps in the background gets killed.
Incident Identifier: 7E6CBE04-D965-470D-A532-ADBA007F3433
CrashReporter Key: bf1c73769925cbff86345a576ae1e576728e5a11
Hardware Model: iPhone3,1
OS Version: iPhone OS 5.1.1 (9B206)
Kernel Version: Darwin Kernel Version 11.0.0: Sun Apr 8 21:51:26 PDT 2012; root:xnu-
1878.11.10~1/RELEASE_ARM_S5L8930X
Date: 2013-03-18 19:44:51 +0800
Time since snapshot: 38 ms
Free pages: 1209
Active pages: 3216
Inactive pages: 1766
Throttled pages: 106500
Purgeable pages: 0
Wired pages: 16245
Largest process: Deja Dev
Processes
Name UUID Count resident pages
geod <976e1080853233b1856b13cbd81fdcc3> 338
LinkedIn <24325ddfeed33d4fb643030edcb12548> 6666 (jettisoned)
Music~iphone <a3a7a86202c93a6ebc65b8e149324218> 935
WhatsApp <a24567991f613aaebf6837379bbf3904> 2509
MobileMail <eed7992f4c1d3050a7fb5d04f1534030> 945
Console <9925a5bd367a7697038ca5a581d6ebdf> 926 (jettisoned)
Test Dev <c9b1db19bcf63a71a048031ed3e9a3f8> 81683 (active)
MobilePhone <8f3f3e982d9235acbff1e33881b0eb13> 867
debugserver <2408bf4540f63c55b656243d522df7b2> 92
networkd <80ba40030462385085b5b7e47601d48d> 158
notifyd <f6a9aa19d33c3962aad3a77571017958> 234
aosnotifyd <8cf4ef51f0c635dc920be1d4ad81b322> 438
BTServer <31e82dfa7ccd364fb8fcc650f6194790> 275
CommCenterClassi <041d4491826e3c6b911943eddf6aaac9> 722
SpringBoard <c74dc89dec1c3392b3f7ac891869644a> 5062 (active)
aggregated <a12fa71e6997362c83e0c23d8b4eb5b7> 383
apsd <e7a29f2034083510b5439c0fb5de7ef1> 530
configd <ee72b01d85c33a24b3548fa40fbe519c> 465
dataaccessd <473ff40f3bfd3f71b5e3b4335b2011ee> 871
fairplayd.N90 <ba38f6bb2c993377a221350ad32a419b> 169
fseventsd <914b28fa8f8a362fabcc47294380c81c> 331
iapd <0a747292a113307abb17216274976be5> 323
imagent <9c3a4f75d1303349a53fc6555ea25cd7> 536
locationd <cf31b0cddd2d3791a2bfcd6033c99045> 1197
mDNSResponder <86ccd4633a6c3c7caf44f51ce4aca96d> 201
mediaremoted <327f00bfc10b3820b4a74b9666b0c758> 257
mediaserverd <f03b746f09293fd39a6079c135e7ed00> 1351
lockdownd <b06de06b9f6939d3afc607b968841ab9> 279
powerd <133b7397f5603cf8bef209d4172d6c39> 173
syslogd <7153b590e0353520a19b74a14654eaaa> 178
wifid <3001cd0a61fe357d95f170247e5458f5> 319
UserEventAgent <dc32e6824fd33bf189b266102751314f> 409
launchd <5fec01c378a030a8bd23062689abb07f> 126
**End**
On closer inspection, the dirty memory consists mostly of Image IO and Core Animation pages. multiple entries consisting of hundreds to thousands of pages. What does Image IO and Core Animation do exactly? and how can I reduce the Dirty Memory?
edit: tried doing this on a serial queue and no improvement on size of Dirty memory
another question. how large is too large for Dirty Memory and allocations?
Updated:
- (void) render
{
for (id thing in mylist) {
#autorelease {
CALayer *layer = createLayerFromThing(thing);
UIImage *img = [self renderLayer:layer];
[self writeToDisk:img];
}
}
}
in createLayerFromThing(thing); I actually creating a layer with a huge amount of sub layers
UPDATED
first screenshot for maxConcurrentOperationCount = 4
second for maxConcurrentOperationCount = 1
============================================================================================================================================================
and since it bringing down the number of concurrent operations barely made a dent,
I decided to try maxConcurrentOperationCount = 10
It's difficult to say what's going wrong without any details but here are a few ideas.
A. Use #autorelease. CALayers generate bitmaps in the backgound, which in aggregate can take-up lots of space if they are not freed in time. If you are creating and rendering many layers I suggest adding an autorelease block inside your rendering loop. This won't help if ALL your layers are nested and needed at the same time for rendering.
- (void) render
{
for (id thing in mylist) {
#autorelease {
CALayer *layer = createLayerFromThing(thing);
[self renderLayer:layer];
}
}
}
B. Also if you are using CGBitmapCreateContext for rendering are you calling the matching CGContextRelease? This goes also for CGColorRef.
C. If you are allocating memory with malloc or calloc are you freeing it when done? One way to ensure that this happens
Post the code for the rendering loop to provide more context.
I believe there are two possibilities here:
The items you create are not autoreleased.
The memory you are taking is what it is, due to the number of concurrent operations you are doing.
In the first case the solution is simple. Send an autorelease message to the layers and images upon their creation.
In the second case, you could limit the number of concurrent operations by using an NSOperationQueue. Operation queues have a property called maxConcurrentOperationCount. I would try with a value of 4 and see how the memory behavior changes from what you currently have. Of course, you might have to try different values to get the right memory vs performance balance.
Autorelease will wait till the end of the run loop to clean up. If you explicit release it can take it from the heap without filling the pool.
- (void) render {
for (id thing in mylist) {
CALayer *layer = createLayerFromThing(thing); // assuming this thing is retained
[self renderLayer:layer];
[layer release]; // this layer no longer needed
} }
Also run build with analyse and see if you have leaks and fix them too.

Security mp_init and init memory leaks

I build an iPad application and profile it with XCode, I got memory leaks in Security framework, following is some of them from Instruments:
Leaked Object # Address Size Responsible Library Responsible Frame
Malloc 128 Bytes,4 < multiple > 512 Bytes Security mp_init
Malloc 128 Bytes, 0x824aa70 128 Bytes Security mp_init
Malloc 128 Bytes, 0x824a9f0 128 Bytes Security mp_init
Malloc 128 Bytes, 0x824a970 128 Bytes Security mp_init
Malloc 128 Bytes, 0x824a8f0 128 Bytes Security mp_init
Leaked Object # Address Size Responsible Library Responsible Frame
Malloc 16 Bytes,4 < multiple > 64 Bytes Security init
Malloc 16 Bytes, 0x824a550 16 Bytes Security init
Malloc 16 Bytes, 0x824a540 16 Bytes Security init
Malloc 16 Bytes, 0x82493d0 16 Bytes Security init
Malloc 16 Bytes, 0x8237ca0 16 Bytes Security init
and some of the details:
# Category Event Type Timestamp RefCt Address Size Responsible Library Responsible Caller
0 Malloc 128 Bytes Malloc 00:02.240.888 1 0x824aa70 128 Security mp_init
# Category Event Type Timestamp RefCt Address Size Responsible Library Responsible Caller
0 Malloc 16 Bytes Malloc 00:02.240.886 1 0x824a550 16 Security init
I use ASIHTTP, FMDatabase and some other frameworks(I do not think they will cause the problem) in my application, and no Security framework in "Link Binary With Libraries", so I have no idea what's going wrong.
Can anyone figure out what may cause the leaks?

Resources