I don't have an o/s running so I can't decode pcie using something like lspci (I wish lspci would take input from a file!).
I have a hex dump below (this is a Xilinx Ultrascale FPGA but the question is generic), I'm trying to understand where the capabilities start and how to decode the Next Cap Pointers to walk the config space. According to Xilinx PG156 page 2-24 the capabilities start at 0x80 from the beginning of the config space, but the values at 0x80 (0x80030001) don't seem to make sense, the next pointer is zero but there are clearly more capabilities.
I can't find a clear answer online or in the standard as to where the capabilities start.
000 0x813410ee
004 0x00100000
008 0x06800000
00c 0x00010000
010 0x0000000c
014 0x00000000
018 0x00000000
01c 0x00000000
020 0x00000000
024 0x00000000
028 0x00000000
02c 0x00000000
030 0x00000000
034 0x000000c0
038 0x00000000
03c 0x00000100
040 0x00000000
044 0x00000000
048 0x00000000
04c 0x00000000
050 0x00000000
054 0x00000000
058 0x00000000
05c 0x00000000
060 0x00000000
064 0x00000000
068 0x00000000
06c 0x00000000
070 0x00000000
074 0x00000000
078 0x00000000
07c 0x00000000
080 0x80030001
084 0x00000008
088 0x00000000
08c 0x00000000
090 0x00800005
094 0x00000000
098 0x00000000
09c 0x00000000
0a0 0x00000000
0a4 0x00000000
0a8 0x00000000
0ac 0x00000000
0b0 0x00000011
0b4 0x00000000
0b8 0x00000000
0bc 0x00000000
0c0 0x00420010
0c4 0x00008023
0c8 0x00012910
0cc 0x0073f043
0d0 0x20410000
0d4 0x00000000
0d8 0x00400000
0dc 0x00000000
0e0 0x00000000
0e4 0x00000012
0e8 0x00000000
0ec 0x0000000e
0f0 0x00030003
0f4 0x00000000
0f8 0x00000000
0fc 0x00000000
100 0x30020001
104 0x00000000
108 0x00400000
10c 0x00462030
110 0x00000001
114 0x0000e000
118 0x00000000
11c 0x00000000
120 0x00000000
124 0x00000000
128 0x00000000
12c 0x00000000
130 0x00000000
134 0x00000000
138 0x00000000
13c 0x00000000
140 0x0001000e
144 0x00000000
148 0x00000000
14c 0x00000000
150 0x30010003
154 0x00000000
158 0x00000000
15c 0x00000000
160 0x00010004
164 0x00000000
168 0x00000000
16c 0x00000000
170 0x00000000
174 0x00000000
178 0x00000000
17c 0x00000000
180 0x00000000
184 0x00000000
188 0x00000000
18c 0x00000000
190 0x00000000
194 0x00000000
198 0x00000000
19c 0x00000000
1a0 0x00000000
1a4 0x00000000
1a8 0x00000000
1ac 0x00000000
1b0 0x00000000
1b4 0x00000000
1b8 0x00010018
1bc 0x00000000
1c0 0x00010016
1c4 0x00000007
1c8 0x00000000
1cc 0x00000100
1d0 0x00000000
1d4 0x00000000
1d8 0x00000000
1dc 0x00000000
1e0 0x00000000
1e4 0x00000000
1e8 0x00000000
1ec 0x00000000
1f0 0x00000000
1f4 0x00000000
1f8 0x00000000
1fc 0x00000000
200 0x00000010
204 0x00000000
208 0x00000000
20c 0x00000000
210 0x00000000
214 0x00010000
218 0x00000000
21c 0x00000553
220 0x00000001
224 0x00000000
228 0x00000000
22c 0x00000000
230 0x00000000
234 0x00000000
238 0x00000000
23c 0x00000000
240 0x00000000
244 0x00000000
248 0x00000000
24c 0x00000000
250 0x00000000
254 0x00000000
258 0x00000000
25c 0x00000000
260 0x00000000
264 0x00000000
268 0x00000000
26c 0x00000000
270 0x00000000
274 0x30010017
278 0x00000005
27c 0x00000000
280 0x00000000
284 0x00000000
288 0x00000000
28c 0x00000000
290 0x00000000
294 0x00000000
298 0x00000000
29c 0x00000000
2a0 0x00000000
2a4 0x00000000
2a8 0x00000000
2ac 0x00000000
2b0 0x00000000
2b4 0x00000000
2b8 0x00000000
2bc 0x00000000
2c0 0x00000000
2c4 0x00000000
2c8 0x00000000
2cc 0x00000000
2d0 0x00000000
2d4 0x00000000
2d8 0x00000000
2dc 0x00000000
2e0 0x00000000
2e4 0x00000000
2e8 0x00000000
2ec 0x00000000
2f0 0x00000000
2f4 0x00000000
2f8 0x00000000
2fc 0x00000000
300 0x30010019
304 0x00000000
308 0x00000000
30c 0x3f003f00
310 0x3f003f00
314 0x3f003f00
318 0x3f003f00
31c 0x00000000
320 0x00000000
324 0x00000000
328 0x00000000
32c 0x00000000
330 0x00000000
334 0x00000000
338 0x00000000
33c 0x00000000
340 0x00000000
344 0x00000000
348 0x00000000
34c 0x00000000
350 0x00000000
354 0x00000000
358 0x00000000
35c 0x00000000
360 0x00000000
364 0x00000000
368 0x00000000
36c 0x00000000
370 0x00000000
374 0x00000000
378 0x00000000
37c 0x00000000
380 0x00000000
384 0x00000000
388 0x00000000
38c 0x00000000
390 0x00000000
394 0x00000000
398 0x00000000
39c 0x00000000
3a0 0x00000000
3a4 0x00000000
3a8 0x00000000
3ac 0x00000000
3b0 0x00000000
3b4 0x00000000
3b8 0x00000000
3bc 0x00000000
3c0 0x00010002
3c4 0x00000000
3c8 0x00000000
3cc 0x00000000
3d0 0x00000000
3d4 0x800000ff
3d8 0x00000000
3dc 0x00000000
3e0 0x00000000
3e4 0x00000000
3e8 0x00000000
3ec 0x00000000
3f0 0x00000000
3f4 0x00000000
3f8 0x00000000
3fc 0x00000000
I don't have an o/s running so I can't decode pcie using something like lspci (I wish lspci would take input from a file!).
lspci can take input from a file!
Use lcpci -xx on one machine to generate the hex output. Save it in a text file. Use lspci -F [filename] to read it in.
Now all you need to do is generate a text file in the same format as that original file (it's just a hex dump of the configuration space).
Ok, I've found out how this works. There are two kinds of capabilites, standard and extended. The pointer to the first standard capability is in the lower 8 bits of the configuration register at offset 0x34.
So
034 0x000000c0
Points to 0xc0
0c0 0x00420010
Where we find the PCIe capability register (0x10), a next pointer (0x00, end of chain) and some metadata (0x0042 ref 7.8.2 of spec to decode).
Separately we have extended capabilities at starting at offset 0x0100 (ref 7.9 of spec).
100 0x30020001
Here we find the Advanced Error Reporting Capability id (0x0001), its version (2) and a next pointer (0x300).
300 0x30010019
Here we find the Secondary PCI Express Extended Capability (0x0019), its version (1) and a next pointer (0x300 - that doesn't make sense as its pointing to itself).
The capabilities pointer are located at address 0x34.
The value you see there is the address to go to.
In you case 0xc0.
At address 0xC0 you have the value 0x10.
This indicates a PCI Express Capability Structure. The next value is 0x00. This indicates the end of a the linked list, otherwise you would have seen an address here and jumped there to continued.
0x10 is a PCI Express Capability Structure
0x05 is a MSI Capability Structure
0x01 is a
As for the PCIe Extended capabilities header structure : I think that there is a mistake.
Bit 15:0 - ID
This is the ID value that can be used to identify the PCIe Extended capability. This value can be modified by setting the property on the PCIe hardblock instance. Read Only.
Bit 19:16 - Rev
This is the Revision ID value that can be used to identify the PCIe Extended capability. This value can be modified by setting the property on the PCIe hardblock instance. Read Only
31:20 - Length
This field indicates the number of bytes in the entire structure, including the PCI Express Extended Capability header, the Vendor-Specific header, and the rest of the data. Read Only
However the information does not make sense with the actual numbers (as you say yourself)....
Related
I am looking at a Linux-Intel-Xeon board which has a PCIe Switch (config Space shown below). On the the other side of the LinuxSwitch, via a CABLE there is a different OtherBoard running my software (non-Intel CPU, non-Linux-OS and BSP, which I understand quite well), and it has another switch and an endpoint/s (EP). From the OtherBoard I want to write to shared memory (e.g. on Linux addres 0xB000 0000), and inform LinuxBoardCpu via MSI.
Focusing on MSI (not general interrupts and not general enumeration). I have two main separate questions:
Q1 How does the SW on the OtherBoard cause an MSI to the LinuxBoard, does the OtherBoard perform a write to Linux 0xFEEE_0D38 (e.g. with data=0x0 or data=0x1)? Or does the OtherBoard write 0x1 to a register on the LinuxBoard's-Switch. I should be able to test this from the Linux side only by writing to 0xFEEE_0D38. How do I get a ptr to that address?
Q2 Just focusing on the LinuxBoard Switch-CPU-Memory: how do I effect the write to LinuxBoard's DRAM/DDR/memory address 0xB000_0000? It seems I need a translation of some some sort at the LinuxCPU. The LinuxSwitch will forward the write-address-data to the LinuxSwitch which forwards to the LinuxCPU, but do I need to setup the LinuxCpu to accept the access, or how does the memory-write access the 0xB000_0000?
I wrote a quick program to explore and dump the Linux PCIeBoard Switch's Config Space
04 10 BAR0 : 0x90800000
05 14 BAR1 : 0x00000000
08 20 MemLim, MemBase : 0x90509050 <<<<\b
09 24 PrefetchMems LnB : 0x90219001
10 28 PrefetchUpBaseAdd : 0x00000000
11 2C PrefecthLimAdd : 0x00000000
12 30 IoLimU16 IoBaseU16: 0x00000000
13 34 ......Cap : 0x00000040
14 38 reserved : 0x00000000
15 3C ....InLine : 0x001001ff
16 40 .... MSICapPtr : 0xc8034801
17 44 : 0x00000008
18 48 MSIintCtrl Nxt ID : 0x01876805
19 4C LowerMsgAddr : 0xfee003d8 <<<<
20 50 UpperMsgAddr : 0x00000000
21 54 .... MsgData : 0x00000000
26 68 Cap, Nxt ID : 0x0052a410
27 6C DevCap : 0x012c8003
28 70 DevStat DevCtrl : 0x00090830
29 74 LnkCap : 0x00416883
30 78 LnkStat ..LnkCtr : 0x10830040
31 7C : 0x00000000
32 80 : 0x00000000
It is really very strange for me as my app is working fine at debug mode & when tried by tester with release build RARELY it gives crash. What I have understood from console log & crash log is that somewhere UI is trying to update from secondary thread but NOT always.
At crash point my console log says,
MyApp[715] <Warning>: CoreAnimation: warning, deleted thread with uncommitted CATransaction; set CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.May 21 10:51:25
MyApp[715] <Warning>: bool _WebTryThreadLock(bool), 0x1e1dd280: Tried to obtain the web lock from a thread other than the main thread or the web thread. This may be a result of calling to UIKit from a secondary thread. Crashing now...May 21 10:51:25
MyApp[715] <Notice>: 1 0x38b048f7 WebThreadLock
& device crash logs crash thread description & error type are as below
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xbbadbeef
Crashed Thread: 15
.
.
.
Thread 15 Crashed: 0
WebCore 0x38b03944_WebTryThreadLock(bool) + 164 1
WebCore 0x38b048f2 WebThreadLock + 62 2
UIKit 0x374424f6 -[UIWebTiledView layoutSubviews] + 38 3
UIKit 0x374424c6 -[UIWebDocumentView layoutSubviews] + 106 4
UIKit 0x373bb7fe -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 254 5
QuartzCore 0x30e92d5e -[CALayer layoutSublayers] + 210 6
QuartzCore 0x30e928fc CA::Layer::layout_if_needed(CA::Transaction*) + 456 7
QuartzCore 0x30e93830 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 12 8
QuartzCore 0x30e93216 CA::Context::commit_transaction(CA::Transaction*) + 234 9
QuartzCore 0x30e93024 CA::Transaction::commit() + 312 10
QuartzCore 0x30ed9df6 CA::Transaction::release_thread(void*) + 166 11 libsystem_c.dylib 0x31150128 _pthread_tsd_cleanup + 172 12
libsystem_c.dylib 0x3114fdfe _pthread_exit + 114 13
libsystem_c.dylib 0x31169160 pthread_exit + 24 14
Foundation 0x358bf226 +[NSThread exit] + 6 15
Foundation 0x35936696 __NSThread__main__ + 998 16
libsystem_c.dylib 0x3115d30e _pthread_start + 306 17
libsystem_c.dylib 0x3115d1d4 thread_start + 4
Thread 15 crashed with ARM Thread State (32-bit): r0: 0xbbadbeef r1: 0x00000000 r2: 0x030ba404 r3: 0x00000001 r4: 0x1e1dd280 r5: 0x3b4cacc0 r6: 0x00000000 r7: 0x030baa74 r8: 0x00000028 r9: 0x00006200 r10: 0x00000000 r11: 0x030bbc70 ip: 0x3b4061e0 sp: 0x030baa6c lr: 0x38b0393b pc: 0x38b03944 cpsr: 0x60000030
I am not very sure about this fix as i have not yet reproduced it at my end. If anyone at-least could help me out for reproducing then it would be great help :)
you do GUI changes in background thread but according to apple you are not changes in GUI in background thread...so use performSelectorOnMainThread to GUI change
This may be a result of calling to UIKit from a secondary thread.
Update the user interface on the main thread.In any of the case for doing UI updates in Separate thread reason will be invalid. One Option is Grand Central Dispatch as it do things in background threads and no crash at all.
I have an iPhone app which works great most of the time, but one time when I downloaded it from the AppStore, I continually got the below error. This error continued until I deleted and reinstalled the application. Note that it did not run correct even once before starting this crash, and this crash happened almost at the exact time I touched the icon. Its strange, because it would not even have time to change any configuration files. Also, as you can see the crash occurred outside of my code. Any information would be appreciated.
Incident Identifier: F1333682-4BC7-44D7-9D7F-485EB7875780
CrashReporter Key: 657dffd01725b5b4b119912904a52134bc517824
Hardware Model: iPhone2,1
Process: iGunPro [9297]
Path: /var/mobile/Applications/A97E28F0-A0A1-45A2-A966-8EB0DC359945/iGunPro.app/iGunPro
Identifier: iGunPro
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2011-12-02 02:26:34.590 -0500
OS Version: iPhone OS 5.0.1 (9A405)
Report Version: 104
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x3744532c 0x37434000 + 70444
1 libsystem_c.dylib 0x3635cf54 0x3630f000 + 319316
2 libsystem_c.dylib 0x36355fe4 0x3630f000 + 290788
3 GraphicsServices 0x321c6444 0x321c2000 + 17476
4 GraphicsServices 0x321c6e84 0x321c2000 + 20100
5 UIKit 0x36fc6520 0x36f95000 + 202016
6 iGunPro 0x00006d20 main (main.m:53)
7 iGunPro 0x0000374c start + 44
Thread 1 name: Dispatch queue: com.apple.libdispatch-manager
Thread 1:
0 libsystem_kernel.dylib 0x374353b4 0x37434000 + 5044
1 libdispatch.dylib 0x36697e78 0x3668b000 + 52856
2 libdispatch.dylib 0x36697b96 0x3668b000 + 52118
Thread 2:
0 libsystem_kernel.dylib 0x37445cd4 0x37434000 + 72916
1 libsystem_c.dylib 0x3631930a 0x3630f000 + 41738
2 libsystem_c.dylib 0x3631909c 0x3630f000 + 41116
Thread 3:
0 libsystem_kernel.dylib 0x37445cd4 0x37434000 + 72916
1 libsystem_c.dylib 0x3631930a 0x3630f000 + 41738
2 libsystem_c.dylib 0x3631909c 0x3630f000 + 41116
Thread 4 name: WebThread
Thread 4:
0 libsystem_kernel.dylib 0x37435010 0x37434000 + 4112
1 libsystem_kernel.dylib 0x37435206 0x37434000 + 4614
2 CoreFoundation 0x33dee41c 0x33d61000 + 578588
3 CoreFoundation 0x33ded154 0x33d61000 + 573780
4 CoreFoundation 0x33d704d6 0x33d61000 + 62678
5 CoreFoundation 0x33d7039e 0x33d61000 + 62366
6 WebCore 0x3483f128 0x34797000 + 688424
7 libsystem_c.dylib 0x3631ec16 0x3630f000 + 64534
8 libsystem_c.dylib 0x3631ead0 0x3630f000 + 64208
Thread 0 crashed with ARM Thread State:
r0: 0x00000000 r1: 0x00000000 r2: 0x00000001 r3: 0x00000000
r4: 0x00000006 r5: 0x3f37ece8 r6: 0x3f52ffe0 r7: 0x2fdffc84
r8: 0x2fdffd60 r9: 0x00272000 r10: 0x00000001 r11: 0x00000000
ip: 0x00000148 sp: 0x2fdffc78 lr: 0x3635cf5b pc: 0x3744532c
cpsr: 0x00000010`
`
This looks as though there is some process running in a background thread that shouldn't. For example, if you attempted some sort of UI manipulation using grand central dispatch that is NOT on the main queue, you might see this behavior. Another example, if you are using core data and you are sharing a managed object context across threads, you may see this behavior.
Something else to consider, there is probably a variable that is being overreleased.
Apple rejected my app two times due to a crash at launch. I have tested it many times on different devices (iPhone 4, iPhone3GS, Simulator, iPad2) and it never crashed.
EDIT: This is a part of the symbolicated crash log.
Thanks!
Incident Identifier: DD9A5C38-DFE5-4CB5-A15B-8C55967FFFD1
CrashReporter Key: bf318d2d968114ff69d458c2f8cbdc6b869e1ec7
Hardware Model: iPhone3,1
Process: iMetroRoma [2788]
Path: /var/mobile/Applications/8EC59E9D-D070-4CAD-892E-91BCE94AA58C/iMetroRoma.app/iMetroRoma
Identifier: iMetroRoma
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2011-10-24 13:23:22.895 -0700
OS Version: iPhone OS 5.0 (9A334)
Report Version: 104
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread: 0
Last Exception Backtrace:
0 CoreFoundation 0x30d828bf __exceptionPreprocess + 163
1 libobjc.A.dylib 0x37f271e5 objc_exception_throw + 33
2 CoreFoundation 0x30ccbb6b -[__NSArrayM objectAtIndex:] + 271
3 iMetroRoma 0x0000426f 0x1000 + 12911
4 CoreLocation 0x34fbc5df -[CLLocationManager onClientEventLocation:] + 1171
5 CoreLocation 0x34fbbf81 -[CLLocationManager onClientEvent:supportInfo:] + 201
6 CoreLocation 0x34fb662f __CLClientInvokeCallback_block_invoke_0 + 55
7 CoreFoundation 0x30d56b31 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 13
8 CoreFoundation 0x30d5615f __CFRunLoopDoBlocks + 159
9 CoreFoundation 0x30d55381 __CFRunLoopRun + 1433
10 CoreFoundation 0x30cd84dd CFRunLoopRunSpecific + 301
11 CoreFoundation 0x30cd83a5 CFRunLoopRunInMode + 105
12 GraphicsServices 0x33906fed GSEventRunModal + 157
13 UIKit 0x32d4a743 UIApplicationMain + 1091
14 iMetroRoma 0x000024e3 0x1000 + 5347
15 iMetroRoma 0x0000249c 0x1000 + 5276
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x3206732c __pthread_kill + 8
1 libsystem_c.dylib 0x3655df54 pthread_kill + 48
2 libsystem_c.dylib 0x36556fe4 abort + 88
3 libc++abi.dylib 0x31a1ff64 abort_message + 40
4 libc++abi.dylib 0x31a1d346 _ZL17default_terminatev + 18
5 libobjc.A.dylib 0x37f272dc _objc_terminate + 140
6 libc++abi.dylib 0x31a1d3be _ZL19safe_handler_callerPFvvE + 70
7 libc++abi.dylib 0x31a1d44a std::terminate() + 14
8 libc++abi.dylib 0x31a1e81e __cxa_rethrow + 82
9 libobjc.A.dylib 0x37f2722e objc_exception_rethrow + 6
10 CoreFoundation 0x30cd853e CFRunLoopRunSpecific + 398
11 CoreFoundation 0x30cd839e CFRunLoopRunInMode + 98
12 GraphicsServices 0x33906fe6 GSEventRunModal + 150
13 UIKit 0x32d4a73c UIApplicationMain + 1084
14 iMetroRoma 0x000024dc 0x1000 + 5340
15 iMetroRoma 0x00002494 0x1000 + 5268
...
Thread 0 crashed with ARM Thread State:
r0: 0x00000000 r1: 0x00000000 r2: 0x00000001 r3: 0x00000000
r4: 0x00000006 r5: 0x3f54dce8 r6: 0x00000002 r7: 0x2fdffa6c
r8: 0x001a1c20 r9: 0x31a20a4a r10: 0x0000d224 r11: 0x0000cbfc
ip: 0x00000148 sp: 0x2fdffa60 lr: 0x3655df5b pc: 0x3206732c
cpsr: 0x00000010
...
Okay, did you "build and archive" when submitting to appstore?
If you did not, tough luck. There is not much you can do now. Even if you did Build and Archive, and lost the archive, you are out of luck.
If you did however, store the archive file of distribution build, very good!
Have you tried opening this in XCode Organizer (drag and drop the file onto organizer, it should try to symbolicate the crashlog). If not, do it.
When you do it, there are two possibilities:
Either the iMetroRoma functions will get symbolicated (meaning you'll see which line is crashing it) or it wont.
X*: If it does, you know where the application is crashing. Posting the details of that would help us solve the issue for you.
If it does not, then automatic symbolication in XCode is not working. Follow these steps (assuming you did all this from XCode 4):
From /Users/your_username/Library/Developer/Xcode/DerivedData remove
all folders.
From /Users/your_username/Library/Application
Support/iPhone Simulator remove all folders.
Clean your trash.
And then try deleting that crash log from XCode Organizer and drag/drop it again there. Possibly, it might symbolicate it now. If it does do step X*, If it does not, read on.
Now, you will need to do follow the steps on this blog. (Very useful and well documented article).
Hopefully, it will symbolicate now and then move to step X*. If it does not, I'm sorry for not being able to help :)
According to the crash log, it looks like an array out of bounds exception. This means that you accessed an array with an index that doesn't exist. Unfortunately, the most important line (3 iMetroRoma 0x0000426f 0x1000 + 12911
) is not symbolicated which means you have to go hunting for all your calls to objectAtIndex: and think about whether there's a possibility that an invalid index could be used.
Would appreciate some insight isolating this, some semi-repeatable crashes in an iPhone app of moderate complexity ...
The crashes in question occur (sometimes, though not consistently) when pressing a UIButton on a particular screen within the app.
(Not sure yet, though the issue may be manifesting itself more under lower memory conditions.)
A typical crash log is excerpted below.
Without getting into a lot of unnecessary detail at this point -- based on the log below, which is typical of several -- would anyone have any insights as to the problem occurring, and where to look and/or how to further troubleshoot?
Any help is very much appreciated!
Thanks.
~~~
Incident Identifier: ...
CrashReporter Key: ...
Process: AppName [1532]
Path: /var/mobile/Applications/12345678-9ABC-DEF0-1234-56789ABCDEF0/AppName.app/AppName
Identifier: AppName
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2010-01-05 18:20:28.081 -0800
OS Version: iPhone OS 3.0.1 (7A400)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x30011944 objc_msgSend + 24
1 UIKit 0x3096e0d0 -[UIApplication sendAction:to:from:forEvent:] + 128
2 UIKit 0x3096e038 -[UIApplication sendAction:toTarget:fromSender:forEvent:] + 32
3 UIKit 0x3096e000 -[UIControl sendAction:to:forEvent:] + 44
4 UIKit 0x3096dc58 -[UIControl(Internal) _sendActionsForEvents:withEvent:] + 528
5 UIKit 0x309a660c -[UIControl touchesBegan:withEvent:] + 260
6 UIKit 0x30935100 _UIGestureRecognizerUpdateObserver + 2136
7 CoreFoundation 0x3020cd8a __CFRunLoopDoObservers + 466
8 CoreFoundation 0x3025488c CFRunLoopRunSpecific + 1812
9 CoreFoundation 0x30254164 CFRunLoopRunInMode + 44
10 GraphicsServices 0x3204529c GSEventRunModal + 188
11 UIKit 0x308f0374 -[UIApplication _run] + 552
12 UIKit 0x308eea8c UIApplicationMain + 960
13 AppName 0x00002090 0x1000 + 4240
14 AppName 0x0000202c 0x1000 + 4140
Thread 1:
0 libSystem.B.dylib 0x31d47158 mach_msg_trap + 20
1 libSystem.B.dylib 0x31d49ed8 mach_msg + 60
2 CoreFoundation 0x3025454e CFRunLoopRunSpecific + 982
3 CoreFoundation 0x30254164 CFRunLoopRunInMode + 44
4 WebCore 0x3588dbc8 __ZL12RunWebThreadPv + 412
5 libSystem.B.dylib 0x31d705a0 _pthread_body + 20
Thread 0 crashed with ARM Thread State:
r0: 0x0019e420 r1: 0x30128c94 r2: 0x00014fac r3: 0x001ce9a0
r4: 0x001a56e4 r5: 0x00000000 r6: 0x00000000 r7: 0x2ffff1e0
r8: 0x00014fac r9: 0x001a97c0 r10: 0x001ce9a0 r11: 0x00000001
ip: 0x388ed9f0 sp: 0x2ffff1b8 lr: 0x3096e0d8 pc: 0x30011944
cpsr: 0x200f0010
~~~
EXC_BAD_ACCESS + objc_msgSend almost always equal a message sent to a deallocated object.
Run the static analyzer and it should help.
Also enabling NSZombies.
Then debug and have fun!