I encountered a crash in my game, here's the crash log (it's a stress test):
PID RPRVT RSHRD RSIZE Command
1 340K 224K 436K launchd
14 124K 160K 216K update
15 568K 164K 620K syslogd
16 792K 612K 1.16M lockdownd
17 2.22M 664K 3.04M mediaserverd
18 296K 160K 440K mDNSResponder
20 540K 568K 1.25M iapd
21 248K 236K 456K fairplayd
22 640K 168K 1012K configd
23 6.42M 6.73M 9.14M SpringBoard
26 660K 212K 1.01M CommCenter
27 308K 164K 620K BTServer
28 19.1M 692K 19.9M TQServer
29 232K 188K 284K notifyd
1830 368K 596K 672K ptpd
1833 140K 164K 280K afcd
1835 148K 164K 288K afcd
1837 140K 160K 260K notification_pro
1848 3.83M 4.89M 4.76M MobileMusicPlaye
1855 19.7M 7.65M 23.6M MyGame ****
1856 616K 5.25M 2.27M MobilePhone
1857 292K 240K 1.25M ReportCrash
The RSIZE of MyGame is only 23.6MB, but the "Memory status: 11" indicate that the program recieves a shutdown command from OS due to memory problem.
So if the memory problem is not caused by my program, is there any way to ignore the shutdown command post from OS?
And from the iPhone develop guide, the OS will terminate a bg process which enconters a memory problem. But the SpringBoard is not terminated. So I think there should be a method to turn the memory management off in program.
You can't ignore the memory warning. The best you can do is try to free up some memory and hope your app doesn't get killed.
See this discussion for some insight.
Related
I do not know why but when y friend gets inebriated she like to hook her phone up to a PC and play with it. she has a basic knowledge of ADB and fastboot commmand and i verified with her what was thrown. When she went to re-lock the bootloader it did not with thisI did. she downloaded Google minimal sdk tools to get the updated ADB and Fastboot then went all the way and got mfastboot from Motorola to insure parsing for flashing. All of these fastboot packages were also tested on Mac and Linux Ubuntu, on Windows 8.1 Pro N Update 1 and Windows 7 Professional N SP2 (all x64). Resulted in the same errors. She is super thorough and I only taught here how to manually erase and flash no scripts or tool kits.
fastboot oem lock
and it returned.
(bootloader) FAIL: Please run fastboot oem lock begin first!
(bootloader) sst lock failure!
FAILED (remote failure)
finished. total time: 0.014s
Then tried again, then again, and then yep again. At this this point she either read the log and followed it. personally though I think based on the point she starts playing with phones it more likely she started to panic because she needs the bootloader locked for work and started attempting to flash.
fastboot oem lock begin
and it returned.
M:\SHAMU\FACTORY IMAGE\shamu-lmy47z>fastboot oem lock begin
...
(bootloader) Ready to flash signed images
OKAY [ 0.121s]
finished. total time: 0.123s
FACTORY IMAGE\shamu-lmy47z>fastboot flash boot boot.img
target reported max download size of 536870912 bytes
sending 'boot' (7731 KB)...
OKAY [ 0.252s]
writing 'boot'...
(bootloader) Preflash validation failed
FAILED (remote failure)
finished. total time: 0.271s
Then the bootloader log stated
cmd: oem lock
hab check failed for boot
failed to validate boot image
upon flashing boot.img the Bootloader Logs lists "Mismatched partition size (boot)".
intresting sometimes it returns
fastboot oem lock begin
...
(bootloader) Ready to flash signed images
OKAY [ 0.121s]
finished. total time: 0.123s
fastboot flash boot boot.img
target reported max download size of 536870912 bytes
sending 'boot' (7731 KB)...
OKAY [ 0.252s]
writing 'boot'...
(bootloader) Preflash validation failed
FAILED (remote failure)
finished. total time: 0.271s
I logged the partitions to see if they are zeroed out indicating bad emmc but they are not.
cat /proc/partitions
cat /proc/partitions
major minor #blocks name
179 0 61079552 mmcblk0
179 1 114688 mmcblk0p1
179 2 16384 mmcblk0p2
179 3 384 mmcblk0p3
179 4 56 mmcblk0p4
179 5 16 mmcblk0p5
179 6 32 mmcblk0p6
179 7 1024 mmcblk0p7
179 8 256 mmcblk0p8
179 9 512 mmcblk0p9
179 10 500 mmcblk0p10
179 11 4156 mmcblk0p11
179 12 384 mmcblk0p12
179 13 1024 mmcblk0p13
179 14 256 mmcblk0p14
179 15 512 mmcblk0p15
179 16 500 mmcblk0p16
179 17 4 mmcblk0p17
179 18 512 mmcblk0p18
179 19 1024 mmcblk0p19
179 20 1024 mmcblk0p20
179 21 1024 mmcblk0p21
179 22 1024 mmcblk0p22
179 23 16384 mmcblk0p23
179 24 16384 mmcblk0p24
179 25 2048 mmcblk0p25
179 26 32768 mmcblk0p26
179 27 256 mmcblk0p27
179 28 32 mmcblk0p28
179 29 128 mmcblk0p29
179 30 8192 mmcblk0p30
179 31 1024 mmcblk0p31
259 0 2528 mmcblk0p32
259 1 1 mmcblk0p33
259 2 8 mmcblk0p34
259 3 16400 mmcblk0p35
259 4 9088 mmcblk0p36
259 5 16384 mmcblk0p37
259 6 262144 mmcblk0p38
259 7 65536 mmcblk0p39
259 8 1024 mmcblk0p40
259 9 2097152 mmcblk0p41
259 10 58351488 mmcblk0p42
179 32 4096 mmcblk0rpmb
254 0 58351488 dm-0
Ive asked for log or the total process to see the full warning, error, and failure message but she is super far on business. From what I do have and what literature i have started to crack. I am starting to believe from all my research and learnng about the android boot proccess. Maybe there is a missing or corrupted key in the SST table which is I beleieved called the bigtable to google. or a hash password failure when locking the bootloader security down or i could be way off please let me know. What I do not know how to investigate or disprove this issue to move on. Would I be able to get confirmation through a stack trace for missing or corrupted coding. So then it can be a puzzle thats solved. Honestly though this has become a puzzle that begs to be solved not an emergency thanks.
You should try "fastboot flashing lock" command instead.
Tue Apr 1 17:21:38.898 [initandlisten] connection accepted from 127.0.0.1:58349 #42 (5 connections now open)
Tue Apr 1 17:21:50.855 [journal] exception in dur::groupCommitLL causing immediate shutdown: boost::filesystem::current_path: Too many open files in system
Tue Apr 1 17:21:50.855 dur4
Tue Apr 1 17:21:50.855 Got signal: 6 (Abort trap: 6).
Tue Apr 1 17:21:50.858 Backtrace:
0x100447d8b 0x100001531 0x7fff9225990a 0x104e80818 0x7fff922b0f61 0x1001e462a 0x10016dc3c 0x10016d537 0x10047a8b5 0x7fff9226b772 0x7fff922581a1
0 mongod 0x0000000100447d8b _ZN5mongo15printStackTraceERSo + 43
1 mongod 0x0000000100001531 _ZN5mongo10abruptQuitEi + 225
2 libsystem_c.dylib 0x00007fff9225990a _sigtramp + 26
3 ??? 0x0000000104e80818 0x0 + 4377282584
4 libsystem_c.dylib 0x00007fff922b0f61 abort + 143
5 mongod 0x00000001001e462a _ZN5mongo10mongoAbortEPKc + 90
6 mongod 0x000000010016dc3c _ZN5mongo3dur27groupCommitWithLimitedLocksEv + 1052
7 mongod 0x000000010016d537 _ZN5mongo3dur9durThreadEv + 583
8 mongod 0x000000010047a8b5 thread_proxy + 229
9 libsystem_c.dylib 0x00007fff9226b772 _pthread_start + 327
10 libsystem_c.dylib 0x00007fff922581a1 thread_start + 13
Would anyone know what is causing mongo to crash? If you need more context please comment - I'll see what else I can dig up.
Change the ulimit value works for me (previously it was 256):
ulimit -n 1000
In this case I'm setting ulimit to 1.000, but you can use whatever value that you want.
According to documentation:
ulimit refers to the per-user limitations for various resources.
Therefore, if your mongod instance executes as a user that is also
running multiple processes, or multiple mongod processes, you might
see contention for these resources. Also, be aware that the processes
value (i.e. -u) refers to the combined number of distinct processes
and sub-process threads.
I'm trying to debug some performance issues with a MongoDB configuration, and I noticed that the resident memory usage is sitting very low (around 25% of the system memory) despite the fact that there are occasionally large numbers of faults occurring. I'm surprised to see the usage so low given that MongoDB is so memory dependent.
Here's a snapshot of top sorted by memory usage. It can be seen that no other process is using an significant memory:
top - 21:00:47 up 136 days, 2:45, 1 user, load average: 1.35, 1.51, 0.83
Tasks: 62 total, 1 running, 61 sleeping, 0 stopped, 0 zombie
Cpu(s): 13.7%us, 5.2%sy, 0.0%ni, 77.3%id, 0.3%wa, 0.0%hi, 1.0%si, 2.4%st
Mem: 1692600k total, 1676900k used, 15700k free, 12092k buffers
Swap: 917500k total, 54088k used, 863412k free, 1473148k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2461 mongodb 20 0 29.5g 564m 492m S 22.6 34.2 40947:09 mongod
20306 ubuntu 20 0 24864 7412 1712 S 0.0 0.4 0:00.76 bash
20157 root 20 0 73352 3576 2772 S 0.0 0.2 0:00.01 sshd
609 syslog 20 0 248m 3240 520 S 0.0 0.2 38:31.35 rsyslogd
20304 ubuntu 20 0 73352 1668 872 S 0.0 0.1 0:00.00 sshd
1 root 20 0 24312 1448 708 S 0.0 0.1 0:08.71 init
20442 ubuntu 20 0 17308 1232 944 R 0.0 0.1 0:00.54 top
I'd like to at least understand why the memory isn't being better utilized by the server, and ideally to learn how to optimize either the server config or queries to improve performance.
UPDATE:
It's fair that the memory usage looks high, which might lead to the conclusion it's another process. There's no other processes using any significant memory on the server; the memory appears to be consumed in the cache, but I'm not clear why that would be the case:
$free -m
total used free shared buffers cached
Mem: 1652 1602 50 0 14 1415
-/+ buffers/cache: 172 1480
Swap: 895 53 842
UPDATE:
You can see that the database is still page faulting:
insert query update delete getmore command flushes mapped vsize res faults locked db idx miss % qr|qw ar|aw netIn netOut conn set repl time
0 402 377 0 1167 446 0 24.2g 51.4g 3g 0 <redacted>:9.7% 0 0|0 1|0 217k 420k 457 mover PRI 03:58:43
10 295 323 0 961 592 0 24.2g 51.4g 3.01g 0 <redacted>:10.9% 0 14|0 1|1 228k 500k 485 mover PRI 03:58:44
10 240 220 0 698 342 0 24.2g 51.4g 3.02g 5 <redacted>:10.4% 0 0|0 0|0 164k 429k 478 mover PRI 03:58:45
25 449 359 0 981 479 0 24.2g 51.4g 3.02g 32 <redacted>:20.2% 0 0|0 0|0 237k 503k 479 mover PRI 03:58:46
18 469 337 0 958 466 0 24.2g 51.4g 3g 29 <redacted>:20.1% 0 0|0 0|0 223k 500k 490 mover PRI 03:58:47
9 306 238 1 759 325 0 24.2g 51.4g 2.99g 18 <redacted>:10.8% 0 6|0 1|0 154k 321k 495 mover PRI 03:58:48
6 301 236 1 765 325 0 24.2g 51.4g 2.99g 20 <redacted>:11.0% 0 0|0 0|0 156k 344k 501 mover PRI 03:58:49
11 397 318 0 995 395 0 24.2g 51.4g 2.98g 21 <redacted>:13.4% 0 0|0 0|0 198k 424k 507 mover PRI 03:58:50
10 544 428 0 1237 532 0 24.2g 51.4g 2.99g 13 <redacted>:15.4% 0 0|0 0|0 262k 571k 513 mover PRI 03:58:51
5 291 264 0 878 335 0 24.2g 51.4g 2.98g 11 <redacted>:9.8% 0 0|0 0|0 163k 330k 513 mover PRI 03:58:52
It appears this was being caused by a large amount of inactive memory on the server that wasn't be cleared for Mongo's use.
By looking at the result from:
cat /proc/meminfo
I could see a large amount of Inactive memory. Using this command as a sudo user:
free && sync && echo 3 > /proc/sys/vm/drop_caches && echo "" && free
Freed up the inactive memory, and over the next 24 hours I was able to see the resident memory of my Mongo instance increasing to consume the rest of the memory available on the server.
Credit to the following blog post for it's instructions:
http://tinylan.com/index.php/article/how-to-clear-inactive-memory-in-linux
MongoDB only uses as much memory as it needs, so if all of the data and indexes that are in MongoDB can fit inside what it's currently using you won't be able to push that anymore.
If the data set is larger than memory, there are a couple of considerations:
Check MongoDB itself to see how much data it thinks its using by running mongostat and looking at resident-memory
Was MongoDB re/started recently? If it's cold then the data won't be in memory until it gets paged in (leading to more page faults initially that gradually settle). Check out the touch command for more information on "warming MongoDB up"
Check your read ahead settings. If your system read ahead is too high then MongoDB can't efficiently use the memory on the system. For MongoDB a good number to start with is a setting of 32 (that's 16 KB of read ahead assuming you have 512 byte blocks)
I had the same issue: Windows Server 2008 R2, 16 Gb RAM, Mongo 2.4.3. Mongo uses only 2 Gb of RAM and generates a lot of page faults. Queries are very slow. Disk is idle, memory is free. Found no other solution than upgrade to 2.6.5. It helped.
i'm new to the iPhone application development, when i'm running my application in device application is crashing and giving following log in organizer
here is the log report :
Incident Identifier: 23B91310-BCEC-497B-821A-8CF8E709ACF7
CrashReporter Key: 3202fd13cd0c5e4ab0706615fabf36ebc9396206
Hardware Model: iPod4,1
OS Version: iPhone OS 4.3.5 (8L1)
Kernel Version: Darwin Kernel Version 11.0.0: Sat Jul 9 00:59:43 PDT 2011; root:xnu- 1735.47~1/RELEASE_ARM_S5L8930X
Date: 2012-08-22 10:45:15 +0530
Time since snapshot: 54 ms
Free pages: 588
Wired pages: 16800
Purgeable pages: 38
Largest process: BJS
Processes
Name UUID Count resident pages
BJS <312d3dae46e433f9982c26738e40060b> 36928 (jettisoned) (active)
debugserver <919dbac91c0e3133a517d6c7a99e667e> 184
SCHelper <f8cf7ee034ac3991a79d8c78e435c1e7> 131
Preferences <cbdecd3d02e031e48e9675235a51306c> 1045 (jettisoned)
springboardservi <5ab19f16a3973514b6d7d62201d6abde> 309
syslog_relay <344c7c41bec5360aae33f4fd412ea95f> 94
notification_pro <698dca6c4cba390a8017315bd25f18f8> 112
syslog_relay <344c7c41bec5360aae33f4fd412ea95f> 97
notification_pro <698dca6c4cba390a8017315bd25f18f8> 108
ptpd <6072e173aed83310b9b7589a70a24b0b> 580
talkmeim <eb62d6230d5f304f9819c6aebc2d2298> 1141 (jettisoned)
lsd <3fafa485b73836acb973d50feabd963a> 248
notifyd <9966082842de313a8e05a001c783faf4> 126
BTServer <01550e9527353eecae41ebee0f889603> 308
CommCenter <7d9446365b4836968ae361626ef8f939> 271
misd <8f94228bddf8342994baf5ca9af1154d> 154
SpringBoard <5c55c6fba0843b0e924e116413b8c9d4> 4143 (active)
accessoryd <d30e340e36df356bbde3347a6ed1ef87> 148
apsd <47ffc9ce9f84371588bd3f937aaa20bb> 285
configd <a6d457fca42732d9ba809d03a2b3e3ae> 401
fairplayd.N81 <144f0ff89c123fa5a1cfa40da72fb024> 165
imagent <9e0b26bad4a538a5b0e5e5ee7eeeb7be> 234
locationd <9088e845dcbe37d890c8758655bf34c6> 685
mDNSResponder <caf94711b8093dc5bc5736306f8ae818> 198
mediaremoted <21af791e80823c9f90f0be2b77a3d885> 199
mediaserverd <c731263114c33a07aef7bccdcf667271> 643
lockdownd <1c7f2b41744c35dc92f679e90a73e240> 268
syslogd <d81669e7bdb93f9b9012020beac826f4> 100
usbethernetshari <25130d2f9a0334e3ae28780250343144> 105
launchd <e2d41e07a0743a089eadbae765709c82> 84
**End**
can any one pls help how to track the log report.
This isn't an application crash, so much as application termination: iOS has a mechanism called Jetsam (or, officially, memory status) which "jettisons" (i.e. throws out) the largest process (in terms of memory) when physical memory is low. This is a necessary measure because iOS has no swap. In your log, which is generated by jetsam, you can see a list of all the processes which were active, and BJS - which has been thrown out. The format is :
Incident Identifier: Automatically generated GUID for Apple
CrashReporter Key: Hash, probably of GUID
Hardware Model: i-Device stepping (4,1 is 4th gen iPod in your case)
OS Version: Version of iOS
Kernel Version: Kernel version, as per uname -a
Date: ... figure this one out
Time since snapshot: How much time has passed - the snapshot may be "dated"
Free pages: How many free pages of RAM remain. Page = 4k
Wired pages: How many resident pages
Purgeable pages: How many pages MAY be freed, if all else fails
Largest process: The culprit
Processes
Name UUID Count resident pages
BJS <312d3dae46e433f9982c26738e40060b> 36928 (jettisoned) (active)
Table, as per column header, where (jettisoned) implies jetsam killed you. (active) implies you were the foreground app.
Hope this helps, (if it doesn't - comment or ask me directly)
How can I setup my app to handle low memory situations? What are best practices?
Incident Identifier: 8BFDA96C-1019-4316-A278-CB86CC67172A
CrashReporter Key: 1657e021ecba3a19c5ed9f0cff62947a426a2bc2
Hardware Model: iPhone3,1
OS Version: iPhone OS 4.1 (8B117)
Date: 2010-09-28 00:00:12 -0700
Time since snapshot: 864 ms
Free pages: 1103
Wired pages: 20977
Purgeable pages: 0
Largest process: SpringBoard
Processes
Name UUID Count resident pages
securityd <3dcc6e23849cb3ee197720700284156d> 231
Reeder <dcb69039fa5b4426b3db9f9920054f3e> 9384
CNN <2da9830626fc69a5885dbb599e7e3910> 5803
Dropbox <2ed4326c3936d079605d309c05d2a7e3> 4340
Evernote <7519f2ea10cad2abbf13ad33177aa69e> 2610
TripIt <37c12bdfbecbf6af9933592e7fae98bd> 2111
MobileMusicPlaye <02ed082c795446617957bbae8974a2c8> 1619
dataaccessd <40c418e18e9bbd950ef7e3fb593645de> 681
Stocks <55e537a6739e58dc068e1436930213ba> 1169
Campfire <15b6957c18195a7fd06c6a3b3f6e0c76> 809
MobileTimer <98640aaee653fc9188652d6cdab13d67> 985 (jettisoned)
BTServer <ce7c062b4df09b835c77a6086b7ef0d8> 349
StockTwits <e8ad700990fe71025d9aeba2dd984cfa> 3482 (jettisoned)
MobileSafari <67a5ebc3754e0ce1e482760c7e56f9c5> 3641 (jettisoned)
mediaremoted <507d59f44f735d6e2855b23a6275557a> 184
Twitter <62edb7ce453c603ad1b8b3bdcbc4910b> 10862
Facebook <ae1fa9da7f8951ffbf693bbd0ed36aaf> 8217
calaccessd <90c4c48a02f0dbf0d1adaad27b8d5945> 526
GV Mobile Plus <179e36b7f3ae7f1f9b784308e1e20f78> 3612
Preferences <9123dcc666c97bb1d63a5921968c8b34> 1662
MobileSMS <bbe1ba067afb113c7be6a7f2e7542da8> 2095
mediaserverd <3ebe3a043c2dba96b70d8ede30bcb6ab> 2178
debugserver <2cd82985d402f2c9daf1b379c72dfd9b> 68
debugserver <2cd82985d402f2c9daf1b379c72dfd9b> 69
SCHelper <30ca097cbb6306cf66157da7fd4de07c> 113
MobileMail <215c71d2434ce352d04786b93cda5340> 5754
MobilePhone <b50b6283b8c52a51fb9e48ee5c909b80> 2859
MobileStorageMou <bd2184fe17b3c9ccbadd9120bd669c99> 101
imagent <4ef86a68405738280f19e5fbc0af56db> 288
lsd <4fb2cf7b5475b39b2c56d9588821eb45> 152
notifyd <ab40010781bef81228df18acf1acdbb2> 171
CommCenter <a8a6257faa2a5213f0a2f5c763f9acfe> 841
SpringBoard <983033e585706c1c6c99eed85cd8dbdb> 18145 (active)
accessoryd <b99ccd1b099c015edb93e8d1cbf03e36> 85
apsd <f031a0e787d8840097a4812fb1c89f5e> 235
awd_ice3 <b598d42ac4fdd950ac5c2c9a1835f70e> 170
configd <b2b3af98743381e759dd5b17115a0378> 449
fairplayd.N90 <3ae05b3bbcb034b0d4d4712e8fc19f99> 80
locationd <963c5d93cfaf1b1139045b1658ecfc26> 935
mDNSResponder <68dc311f118d171ede7b91f43c323b7d> 202
lockdownd <bfeda752b819f06f4828e112d3ca695c> 341
syslogd <60e8005a73e76d6ee81a8b45a9443a16> 84
launchd <b15ff1a8f2f37c3b0df0343899757b17> 104
**End**
handle -didReceiveMemoryWarning in your controllers and run your code through analyzer.
work with NSZombieEnabled, this link might be helpful
http://www.frogameleon.com/blog/last-night-an-iphone-zombie-nszombieenabled-saved-my-life
Try to run your application with Leaks (Run->Run with Performance Tools->Leaks), and see if you can find any leaks.
You should always release stuff you're not using anymore to reduce your memory-footprint.
See this question: iPhone Development - Memory limitation for iphone application