I've been working on a small app, actually in final staging of polish and debug.
I made few small changes to NSUserDefaults storage, which were very minor changes.
However, every time I try to run the app on iPod I get a weird LLDB error, without any further info, like which file, library etc... I set up breakpoints in application:didFinishLoadingWithOptions, but the error is before that?? The app is stuck on splashscreen.
Dump if it is on any help...
Thread 1: EXC_BAD_ACCESS (code=2, address=0x2fd77d4c)
0x2fd77d4c: svchs #14122336
0x2fd77d50: svchs #14122908
0x2fd77d54: svchs #14122923
0x2fd77d58: svchs #14122954
0x2fd77d5c: andeq r0, r0, r0
0x2fd77d60: rsbvc r7, r1, #49283072
0x2fd77d64: rsbvs r6, pc, #3008
0x2fd77d68: svchs #6646889
Does an empty project works with your iPOD? If the answer is yes, comment out all codes you wrote then uncomment it part by part to find which part caused this issue, vise versa.
It's always effective to slice suspect codes to pieces when you can't locate the issue.
i connect to iphone's debugserver and able to send GDB Serial Protocol packets. I can set breakpoint and wait until it reached. When it did i want to call objc_msgSend with known parameters, get it's output and continue execution. For now i am simulating it's process in xcode and lldb, so i can not use just 'call objc_msgSend(object, _cmd)'.
what i do:
set breakpoint to some code
register read pc // read next operation address
register write lr 0x0x0000253a // set return address to continue execution (pc value)
register write pc 0x30300c88 // my objc_msgSend address
register write r0 0x16ed30 // my object address
register write r1 0x3161 // my selector address
breakpoint set -a 0x0x0000253a
continue
So i have my method called, but then app crashes and never reaches my 'return address' 0x0x0000253a. Also it rewrites r0 with return value, so my method is totally incomplete. I understand that what i do is hardcore overwriting registers without storing and restoring previous values so please help. How can i store/restore registers state, what i am doing wrong or what necessary things i do not do?
Also it could be very helpful to trace xcode's debugger for what it is doing while 'call objc_msgSend'. I tried to use this code and fruitstrap to use dtruss and then research it's output - it had thousands of memory reads and breakpoint sets, useless for me.
Note: i can use only GDB Serial Protocol.
I'm in Xcode using the gdb debugger, I just don't understand the error messages I am getting, they seem to change after every run too.
Here is a snippet of the code that is being shown:
0x001e8975 <+0006> sub $0xc,%esp
0x001e8978 <+0009> call 0x1e897d <prepareForMethodLookup+14>
0x001e897d <+0014> pop %edi
0x001e897e <+0015> mov 0x8(%ebp),%esi
0x001e8981 <+0018> mov 0x10(%esi),%eax
0x001e8984 <+0021> and $0xfffffffc,%eax
0x001e8987 <+0024> cmpl $0x0,(%eax)
0x001e898a <+0027> js 0x1e89d2 <prepareForMethodLookup+99>
0x001e898c <+0029> mov 0xfe697(%edi),%ebx
0x001e8992 <+0035> cmpl $0x0,(%ebx)
0x001e8995 <+0038> je 0x1e89aa <prepareForMethodLookup+59>
0x001e8997 <+0040> cmpl $0x2,0x103df7(%edi)
The line in the middle there is where the green arrow seems to be pointing. I just don't fully understand what it means. I'd paste some of the code, but I'm not entairly sure where the actual problem is, and theres a lot of code. It's probably a noob question, or I may not have explained it very well, but I'd appreciate the help.
Do you have exception breakpoints enabled?
Press CMD-6 while in XCode
This should change you from project explorer to breakpoints on your left hand tab
Click the little + at the bottom left of the page and "Add Exception Breakpoint", this adds a breakpoint for all exceptions that happen in the app.
I'm not sure why they're not on by default, it's a little annoying!
This may help you track down the problem you're facing.
I have spent quite some time trying to trace this problem and read multiple suggestion from others with the same problem. I deal with a large code base so finding the problem without some hints is like looking for a needle in a hay stack.
On of the suggestion I read is to add a break point on *malloc_error_break* - but how do I do that. I understand that I have to add a symbolic break point but I'm not sure what exactly to enter in the two text fields, Symbol and Module?
I tried to enable Malloc Scribble and Malloc Guard Edges - but none of it results in any break point or crashes.
If I enable Zombie Objects the programs stops crashing but there is nothing in the output log showing any problems.
Finally I tried to enable Guard Malloc. I understand that it only works with the simulator so I tries that - but the problem is that the programs crashes in the start up phase before any line in my program is executed:
0x958e0cd4 <+0000> mov 0x4(%esp),%eax
0x958e0cd8 <+0004> mov %gs:0x0(,%eax,4),%eax < Crash
0x958e0ce0 <+0012> ret
and the call stack looks like this:
pthread_getspecific
__dyld__dyld_start
I'm not sure what I'm doing wrong here?
To add a breakpoint on malloc_error_break, simply stop in the debugger and type b malloc_error_break at the "gdb" or "lldb" prompt.
i profiled a portion of my application using the Delphi Sampling Profiler. Like most people, i see a majority of the time spent inside ntdll.dll.
Note: i turned on the options to ignore Application.Idle time, and calls from System.pas. So it
isn't inside ntdll because the
application is idle:
After multiple runs, multiple times, the majority of the time seems to be spent inside ntdll.dll, but the odd thing is who the caller is:
The caller is from the Virtual Treeview's:
PrepareCell(PaintInfo, Window.Left, NodeBitmap.Width);
Note: The application is not inside ntdll.dll because the
application is idle, because the
caller isn't Application.Idle.
What confuses me is that it's this line itself (i.e. not something inside PrepareCell) is the caller into ntdll. Even more confusing is that:
not only is it not something inside PrepareCell()
it's not even the setup of PrepareCell (e.g. popping stack variables, setting up implicit exception frames, etc) that is the caller. Those things would show up in the profiler as a hotspot on the begin inside PrepareCell.
VirtualTrees.pas:
procedure TBaseVirtualTree.PrepareCell(var PaintInfo: TVTPaintInfo; WindowOrgX, MaxWidth: Integer);
begin
...
end;
So i'm trying to figure out how this line:
PrepareCell(PaintInfo, Window.Left, NodeBitmap.Width);
is calling ntdll.dll.
The only other ways in are the three parameters:
PaintInfo
Window.Left
NodeBitmap.Width
Maybe one of those is a function, or a property getter, that would call into ntdll. So i put a breakpoint on the line, and look at the CPU window at runtime:
There is a line in there that might be the culprit:
call dword ptr [edx+$2c]
But when i follow that jump, it doesn't end up in ntdll.dll, but TBitmap.GetWidth:
Which, as you can see, doesn't call anywhere; and certainly not into ntdll.dll.
So how is the line:
PrepareCell(PaintInfo, Window.Left, NodeBitmap.Width);
calling into ntdll.dll?
Note: i know full well it isn't really calling into ntdll.dll. So any valid answer will have to include the words "Sampling Profiler is misleading; that line is not calling into ntdll.dll." The answer will also have to either say that the majority of the time is not spent in ntdll.dll, or that the highlighted line is not the caller. Finally any answer will have to explain why Sampling Profiler is wrong, and how it can be fixed.
Update 2
What is ntdll.dll? Ntdll is Windows NT's native API set. The Win32 API is a wrapper around ntdll.dll that looks like the Windows API that existed in Windows 1/2/3/9x. In order to actually get into ntdll you have to call a function that uses ntdll directly or indirectly.
For example, when my Delphi application goes idle, it waits for a message by calling the user32.dll function:
WaitMessage;
When when you actually look at it is:
USER32.WaitMessage
mov eax,$00001226
mov edx,$7ffe0300
call dword ptr [edx]
ret
Calling the function specified at $7ffe0300 is the way Windows transitions into Ring0, calling the FunctionID specified in EAX. In this case, the System Function being called is 0x1226. On my operating system, Windows Vista, 0x1226 corresponds to the system function NtUserWaitMessage.
This is how to you get into ntdll.dll: you call it.
i was desperately trying to avoid a hand-waving non-answer when i worded the original question. By being very specific, carefully pointing out the reality of what i'm seeing, i was trying to prevent people from ignoring the facts, and trying to use a hand-waving argument.
Update Three
i converted the two parameters:
PrepareCell(PaintInfo, Window.Left, NodeBitmap.Width);
into stack variables:
_profiler_WindowLeft := Window.Left;
_profiler_NodeBitmapWidth := NodeBitmap.Width;
PrepareCell(PaintInfo, _profiler_WindowLeft, _profiler_NodeBitmapWidth);
To confirm that the bottleneck is not is the call to
Windows.Left, or
Nodebitmap.Width
Profiler still indicates that the line
PrepareCell(PaintInfo, _profiler_WindowLeft, _profiler_NodeBitmapWidth);
itself is the bottleneck; not anything inside PrepareCell. This must mean that it's something inside the setup of the call to prepare cell, or at the start of PrepareCell:
VirtualTrees.pas.15746: PrepareCell(PaintInfo, _profiler_WindowLeft, _profiler_NodeBitmapWidth);
mov eax,[ebp-$54]
push eax
mov edx,esi
mov ecx,[ebp-$50]
mov eax,[ebp-$04]
call TBasevirtualTree.PrepareCell
Nothing in that calls into ntdll. Now the pre-amble in PrepareCell itself:
VirtualTrees.pas.15746: begin
push ebp
mov ebp,esp
add esp,-$44
push ebx
push esi
push edi
mov [ebp-$14],ecx
mov [ebp-$18],edx
mov [ebp-$1c],eax
lea esi,[ebp-$1c]
mov edi,[ebp-$18]
Nothing in there calls into ntdll.dll.
The questions still remain:
why is pushing of one variable onto the stack, and two others into registers the bottleneck?
why isn't anything inside PrepareCell itself the bottleneck?
Well, this problem was actually my main reason to make my own sampling profiler:
http://code.google.com/p/asmprofiler/wiki/AsmProfilerSamplingMode
Maybe not perfect, but you could give it a try. Let me know what you think about it.
Btw, I think it has to do with the fact that almost all calls ends into calls to the kernel (memory requests, paint events, etc). Only calculations do not need to call the kernel.
Most calls ends in waiting for kernel results:
ntdll.dll!KiFastSystemCallRet
You can see this in Process Explorer with thread stack view, or in Delphi, or using StackWalk64 API in my "Live view" of AsmProfiler:
http://code.google.com/p/asmprofiler/wiki/ProcessStackViewer
There are probably two things happening there.
The first is that SamplingProfiler identifies the caller by walking up the stack, until it encounters what looks like a valid call point into Delphi from Delphi code.
The thing is, some procedures may reserve a large amount of stack at once, without reinitializing it. This could result in a false positive. The only clue then would be that your false positive was recently invoked.
The second thing is the ntdll localization, that is known for certain, however, ntdll is your wait point in user-space, and as user197220, ntdll is where you'll end up waiting most of the time you're calling system stuff and waiting for the result.
In your case, unless you reduced the sampling rate, you're looking at 247ms of CPU work time, which could probably pass as idle if those 247 samples were collected over many seconds of real time. Since the false positive points to VirtualTree paint preparations, my bet would be that the ntdll time is actually paint time (driver or OS software).
You can try commenting out the code that actually does the painting to be sure.