I have written a objective-c wifi library and a c wrapper around it to call from my c++ code using corewlan framework.I have setup timers and on expiry of the timer i call scanwifi function of the library which gives details of all the wifi network details.The program keeps crashing by giving malloc error incorrect check sum for freed object. The crash is not consistent,keeps appearing a random places. I tried guard malloc to find the memory bug, left the program running for more than 10 hours but it didn't crash. as soon as i removed guard malloc and executed the program and boom there was the crash. Can anyone please tell ways to catch this memory bug
Thanks
Memory management errors can be particularly difficult to track down; without seeing code it's hard to say.
You mentioned GuardMalloc—have you tried enabling other Diagnostics?
Scribble
Guard Edges
Guard Malloc
Zombie Objects
This can help debugging by making your code crash more predictably—hopefully closer to the source of the error.
(In Xcode 4.4.1, these are set via "Product"->"Edit scheme"->"Run"->"Diagnostics".)
Related
I am currently writing a game rendering engine using LWJGL 3 and Kotlin. Everything works fine for multiple minutes, until out of nowhere the program exits with the following message:
Process finished with exit code -1073740940 (0xC0000374)
All I do is load a few models, and then render them with glDrawElements(...) in the main loop - nothing else is loaded or changed.
Now, I know that this error code means heap corruption, but I do not even get a hs_err_pid logfile and the Java Debugger just crashes with the program. So how would I go about debugging such a crash? Could this be because of an incompatibility with Kotlin?
So, for everyone who may find themselves in a similar situation: Thanks to the LWJGLX debug tool by Kai Burjack, I instantly found what crashed the program.
What I did was the following: In the shader class, when uploading a matrix, I allocated a managed FloatBuffer, which I then accidentally tried to free manually:
val buf = BufferUtils.createFloatBuffer(16)
matrix.get(buf)
glUniformMatrix4fv(location, false, buf)
MemoryUtil.memFree(buf)
The MemoryUtil.memFree() call actually doesn't crash, but as the matrix changes every frame, this method corrupts the heap over time - hence the crash after a few minutes.
I attached the LWJGLX debugger and now my program crashed instantly - with a precise error message telling me that I am trying to free a Memory Region i did not allocate with memAlloc() - So after changing my code to
val buf = MemoryUtil.memAllocFloat(16)
...
MemoryUtil.memFree(buf)
everything now works. I can only recommend the LWGLX debugger - It also found some memory leaks I now have to fix ;-)
My iOS app is randomly crashing but I don't get any warning/error in the console. I think it might be a memory leak but shouldn't I receive a EXC_BAD_ACCESS error at least ?
The other thing might be a memory overloading, but I don't get any memory warning and I've just tested the app with the instruments tool.
So why does it crash without printing anything in the console ?
Thanks
UPDATE:
I'm actually getting a memory warning in the instruments although I don't see the memory to increase. COuld be the cause of the crash ? How do i know where is the memory warning generated ? (See screenshot: )
Tell your program to print a backtrace every time it receives a low memory warning.
From Apple documentation:
UIKit provides several ways to receive low-memory notifications, including the following:
Implement the applicationDidReceiveMemoryWarning: method of your
application delegate.
Override the didReceiveMemoryWarning method in
your custom UIViewController subclass.
Register to receive the
UIApplicationDidReceiveMemoryWarningNotification notification.
Enable Zombie objects and try again. https://stackoverflow.com/a/8050701/1271579
Edit: If the device runs out of memory, you will recieve a few memory warnings before crashing so you should probably optimize it.
My Mac app is crashing with exc_bad_access on the run loops.
So I enabled NSZombies, and Now I don't see such error as expected ( As the objects are not de-allocated).
But, I don't find any useful NSZombie Log in the console.
Is there a way to identify the issue ?
It's challenging. The most common cause of this error in Cocoa is directly accessing your ivars rather than using accessors. Accessors make the vast majority of memory crashes go away.
That said, they're not the only cause of memory errors. You may be accessing memory other ways. NSZombie does one specific thing: When you deallocate an object, NSZombie says "don't actually deallocate the object." Instead it turns the object into a zombie object that prints an error if you send it messages. But that only helps if the crash is due to sending a message to a deallocated instance. It could be lots of other things.
You should start first with the crash stack itself. Look up the stack and see what kind of object it might be, or who might be calling it.
Read TN2124, particularly the section on the BSD Memory Allocator, and the Enabling the Malloc Debugging Features section of the memory Usage Performance Guidelines. There are lower-level tools than NSZombie that you can use. MallocScribble is often the most useful. It overwrites deallocated memory with 0x55 so that you're more likely to crash sooner, and to make it easier to detect deallocated memory in the debugger. MallocPreScribble is useful for finding uninitialized memory, but this really only helps if you do raw malloc calls. ObjC objects are always pre-initialized.
And of course you have to put on your detective hat. What parts of your program are most suspicious? Are you doing multi-threaded work (that can cause memory crashes if you don't lock correctly).
If it reproduces easily, then you'll figure it out. If it only happens occasionally, well... I've hunted bugs like that for many months sometimes. Sometimes it's just hard.
You need to use memory profiler for that. Just build with Profile option and select Leaks.
I'm currently working on a game for iPhone/iPad using Cocos2D.
On the simulator it works fine and can run for hours, without any problems.
But on a device, it runs for some time and then just crashes out of nowhere. The debug console gives no error message, typing in "bt" just returns "No stack." and it doesn't generate a crash report.
It mostly crashes when loading the main menu or a new level but it can happen while playing a level as well.
Any ideas on how to debug this?
You should really read about memory management in objective-c
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html
When I first switched to programming in objective-c (from C#/Java background), I had a lot of problems too. Once I understood memory management in objective-c, I rarely have those kind of problems. I don't use arc.
Whenever you alloc & init an object, the retain count is 1. You should remember to release these objects at some point. If you use other methods, then you get an autorelease object. That is the convention.
The time you will save is really worth it.
Please help me track down an iOS memory leak. Thanks!
I'm using xCode 4.0.1 and I tried to activate NSZombie to track a memory leak, but it doesn't seems to work as before, with xCode 3.x
I can't find out where the memory leak is coming from, as Instruments points this out:
Leaked Object -> GeneralBlock-32
Address -> 0x4c8600
Size -> 32 Bytes
Responsible Library -> libsystem_c.dylib
Responsible Frame/Caller -> strup
At this point I don't know If I'm using Instruments with NSZombie the right way with xCode 4, as it doesn't show the NSZombie option when I click "i" for more information, under the left option Leaks.
OBSERVATION: My iPhone application plays a live stream mms/wma and also wma áudio files with a finite amount of time. The leak happens only with a finite wma file, but runs perfectly when I'm playing from a streamed source, with no ending time.
First, that is a malloc block, not an object. Zombies won't work (and would never have worked in prior versions either).
How many times does that leak happen? Once? Don't worry about it. Once per stream? file a bug -- that isn't in your code from what you have posted so far (unless your code is calling strdup, which is certainly possible but atypical in most iOS apps that aren't making heavy use of third party libraries... are you?)
In any case, unless it is leaking 100s and 100s of 32 byte allocations across the runtime of your app, don't worry about it (but please do file a bug).
As Valkio said, you can grab the stack trace of the allocation from gdb (or from Instruments) directly.
You can see where it was allocated if you do this:
Go to Product -> Edit Scheme -> Run
(Debug) -> Arguments.
Add this to environment variables: MallocStackLoggingNoCompact
Set it to YES
Run, and let it crash.
type in console (gdb) info malloc 0x4c8600 or whatever the address is.