I'm using gdb (release 1708 from radare.org) on iOS 6.0.1 to debug an unknown app. For some reason I want to allocate memory, which should work via "call (char*)malloc(size)". I already browsed a lot of samples using such calls (for instance here) but all of these calls fail.
(gdb) call (char*)malloc(4)
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000004
0x37af2060 in strcpy ()
The program being debugged was signaled while in a function called from GDB.
GDB has restored the context to what it was before the call.
To change this behavior use "set unwindonsignal off"
Evaluation of the expression containing the function (malloc) will be abandoned.
or
(gdb) print (float) fabs (3.0)
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x40080000
0x37b18040 in T_CString_int64ToString ()
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (T_CString_int64ToString) will be abandoned.
Why would malloc access memory at the parameter "size"? Anly ideas how to fix this? Or is the gdb version simply not ready for iOS 6.X? The actual call seems to work, but internal Functions cause the failure (T_CString_int64ToString).
It appears that GDB is attempting to access an unmapped memory region, which is the address returned by the malloc call. Try attaching to a known application/process and see if the malloc call works.
Have you tried release 1821?
it's available from CrackLords Repository, add it to cydia to get this version
or alternatively you can follow these instructions to sign it yourself A working GNU Debugger on iOS >= 4.3
Related
When building and running my iOS app from xcode, the following message appears in the terminal (iPhone 4s running 9.3.6).
Could not find implementation lookup function
"class_getMethodImplementation" step in through ObjC method dispatch
will not work.
This message does not appear on my iPhone X on iOS 14.4.
What does this mean? I have been unable to find any documentation related to this message.
It is a warning from LLDB (the debugger) saying that it cannot find class_getMethodImplementation (a method in the Obj-C runtime), and that will prevent it from stepping through message dispatch.
Which may not help you much... Why LLDB cannot find that method is something you'll have to figure out, as is whether it is a significant warning.
You can find the LLDB error on line 726 of this source file.
HTH
Nvwa crashes on free calls in its delete operator overrides, especially on simulator, with error:
malloc: *** error for object [hexadecimal address]: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
Your leak detection library apparently and ironically has a heap corruption bug, likely use-after-free. I suggest you use Instruments or malloc history to determine what that address previously corresponded to and then audit the lifecycle of that allocation and pointers to it.
It's all about compilation settings on the target that you use to build the library.Nvwa uses platform-specific macros to recognise available threading libraries and it so happens that _PTHREADS is not normally defined on iOS and I did not allow C++11 mutexes by NOT defining NVWA_USE_CXX11_MUTEX set to 1. So we have few alternatives, either define _PTHREADS, allow use of C++11 mutexes or change Nvwa code to also check for _POSIX_THREADS macro... One of the places that absolutely require "proper" mutexes is the update of allocation list that is used to report leaks (in debug_new.cpp). Without synchronising there, next element pointers are bound to eventually point to released memory and use-after-free is just a matter of time.
Every once in a while, while debugging an application on an iPad (OS 6.1.3, SDK 6.1), the program pauses after receiving a SIGTRAP signal. I first noticed this happening inside the stat function (from /usr/include/stat.h), but it's also happening in a few other places, like semwait_signal (from nanosleep). The most obvious pattern is that it always happens immediately after running the instruction svc #128. In the case of stat, it returned 0 and there were no errors, so it doesn't seem to indicate any kind of failure state.
Has anyone else experienced this, or know how to get around it?
Thanks!
Unfortunately I didn't discover why exactly the SIGTRAP was being raised by these basic functions, but this symptom went away when I fixed a larger problem with my iOS project.
The app target and static library targets I was linking in didn't consistently define the preprocessor macro _DEBUG, which generated some weird assembly. They had the same levels of optimization, but apparently including/excluding _DEBUG made enough of a difference to cause problems.
When I crash (for reasons I understand; that's not the problem) when I try to do something Cocoa isn't okay with, such as calling a method that doesn't exist or attempting to insert nil into a set, the debugger shows the stack from main() to __pthread_kill, without any of the frames that were present when the actual crashing code ran. There is a frame (9th from main) called objc_exception_rethrow. This leads me to believe that Cocoa Touch is trying to do something or other to recover all exceptions and die gracefully or something. However, it is very irritating when debugging to not have the ability to actually use Xcode4's debugging tools to investigate the calling stack frames, or even see where in my code I crashed.
Is there some way to make the objc_exception_rethrow behavior not happen, and just crash as soon as an exception is raised? Perhaps there's a debug setting that makes it crash earlier (at the right time)? (I haven't messed with any of the build settings in this project yet.)
I don't know any Xcode setting that could disable re-throwing exceptions. To my knowledge they are re-thrown by the runtime. You could try running the app without the debugger attached and let it crash. The crash report should contain a section "Last Exception Backtrace" which will give you exactly what you need in this case.
I found the answer: set a breakpoint on Obj-C Exceptions. It will go to the debugger when objc_exception_throw is hit, which is good. Unfortunately, this happens before the exception is printed, but we can make that happen anyway (most of the time) by setting the breakpoint's action to be (Debugger Action) po *(id *)($ebp + 8).
Our DUnit project is crashing on exit. It crashes if "Run Without Debugging", but doesn't crash if I Run inside the debugger.
If I attach the debugger to the process after starting it, it does not crash on exit.
I suspected a problem in finalization, so I put print statements in all the finalization code I suspected was running. This turned up nothing useful. Finalization for one of our low level Units (with no dependencies on any non-system Units) is running correctly. So it still could be finalization, but it may not be.
The crash produces this dialog:
Problem signature:
Problem Event Name: APPCRASH
Application Name: MCLTesting.exe
Application Version: 0.0.0.0
Application Timestamp: 4eb07b50
Fault Module Name: kernel32.dll
Fault Module Version: 6.0.6001.18215
Fault Module Timestamp: 49953395
Exception Code: c0000005
Exception Offset: 000bf395
OS Version: 6.0.6001.2.1.0.256.6
Locale ID: 3081
Additional Information 1: b37c
Additional Information 2: 2a7328d8bb40c81c93b4b5f46adb8e10
Additional Information 3: b37c
Additional Information 4: 2a7328d8bb40c81c93b4b5f46adb8e10
"Exception Code: c0000005" Does that mean anything?
The main clue I have is the fact that it doesn't crash in the debugger. Has anyone seen that before?
I finally tracked this down.
The problem was indeed in a finalizer. A user exception was being thrown in a finalizer. The exception was not caught, and the exception itself was being leaked (The Exception and its string were not freed). It seems this memory leak was causing the crash? I'm not sure why I didn't notice this memory leak when I originally posted.
Catching the exception fixed the crash problem.
One interesting thing I found out is that even if an uncaught exception is thrown in a finalizer, subsequent Unit's finalizers will still be run. I was assuming that a problem in one finalizer would stop all subsequent finalizers from running.
The method I used to find the offending Unit was very simple; I removed all units from my project, then reintroduced Units one by one until I got the crash bug. Time consuming but it worked in the end.
Exception code c0000005 is an access violation. This usually means one of two things: either you're attempting to dereference a pointer or object reference that's set to nil, or you're working with corrupted memory.
The other pertinent piece of data in the error report is Exception Offset: 000bf395. That tells you where the error is occurring. Try looking up f395 in your map file and see if you can't find a unit finalization that corresponds to that memory offset. If so, that should give you a good idea as to what's going wrong.