Most of the time when recording, the memory footprint for mm-camera-daemon remains below 20MB: [07/16/14 13:44:26] User 37%, System 36%, IOW 0%, IRQ 0% [07/16/14 13:44:26] User 148 + Nice 97 + Sys 236 + Idle 167 + IOW 1 + IRQ 0 + SIRQ 0 = 649 [07/16/14 13:44:26] [07/16/14 13:44:26] PID PR CPU% S #THR VSS RSS PCY UID Name [07/16/14 13:44:26] 293 1 11% S 57 206460K 86640K root /system/b2g/b2g [07/16/14 13:44:26] 948 1 13% S 30 111964K 48676K u0_a948 /system/b2g/plugin-container [07/16/14 13:44:26] 906 0 0% S 17 103764K 38024K u0_a906 /system/b2g/plugin-container [07/16/14 13:44:26] 950 1 0% S 17 71272K 29340K u0_a950 /system/b2g/plugin-container [07/16/14 13:44:26] 863 1 0% S 14 54140K 20712K root /system/b2g/plugin-container [07/16/14 13:44:26] 1223 0 0% S 16 60040K 19180K u0_a1223 /system/b2g/plugin-container [07/16/14 13:44:26] 364 1 15% S 22 45596K 12524K camera /system/bin/mm-qcamera-daemon [07/16/14 13:44:26] 285 1 8% S 27 63912K 11620K fg media /system/bin/mediaserver [07/16/14 13:44:26] 320 0 0% S 15 26564K 5728K radio /system/bin/rild [07/16/14 13:44:26] 323 1 0% S 15 26568K 5684K radio /system/bin/rild However it can be put into high memory state, which it gets stuck in, even when recording is stopped, the camera application is closed and the device is left idle: [07/16/14 13:50:43] User 0%, System 4%, IOW 0%, IRQ 0% [07/16/14 13:50:43] User 6 + Nice 0 + Sys 29 + Idle 600 + IOW 0 + IRQ 0 + SIRQ 1 = 636 [07/16/14 13:50:43] [07/16/14 13:50:43] PID PR CPU% S #THR VSS RSS PCY UID Name [07/16/14 13:50:43] 364 1 0% S 6 129416K 121084K camera /system/bin/mm-qcamera-daemon [07/16/14 13:50:43] 293 1 0% S 57 206220K 87568K root /system/b2g/b2g [07/16/14 13:50:43] 906 0 0% S 17 115240K 44892K u0_a906 /system/b2g/plugin-container [07/16/14 13:50:43] 948 1 0% S 29 108028K 39520K u0_a948 /system/b2g/plugin-container [07/16/14 13:50:43] 950 0 0% S 17 71272K 29340K u0_a950 /system/b2g/plugin-container [07/16/14 13:50:43] 863 0 0% S 14 54140K 20712K root /system/b2g/plugin-container [07/16/14 13:50:43] 1223 1 0% S 16 60040K 19180K u0_a1223 /system/b2g/plugin-container [07/16/14 13:50:43] 285 0 0% S 13 29988K 8608K fg media /system/bin/mediaserver [07/16/14 13:50:43] 320 0 0% S 15 26564K 5728K radio /system/bin/rild [07/16/14 13:50:43] 323 1 0% S 15 26568K 5684K radio /system/bin/rild -- STR: 1) Loaded latest master build (eng.cltbld.20140716.071512) on flame. 2) Recorded several short videos watching this gif without any problems: http://seamac.info/cupboard/cinema/gif/animoshuns/saverlab/plasma3.gif 3) Alternated between short recordings, switching modes and taking pictures, memory footprint remains normal. 4) Recorded longer video watching the above gif, zoomed into use most of the laptop screen. All normal. 5) Physically moved the camera in and out, such that the gif would slowly come out of view and capture more of the laptop in the preview. This would frequently lead to a darkening of the preview (but still visible). 6) Once darkened, move back towards the gif such that it fills the whole screen. Preview should go to black and memory for mm-qcamera-daemon should begin to rise. 7) Repeat steps 5 and 6 to continue raising the memory if desired. 8) End recording, memory footprint does not go down. 9) Exit camera app, reenter camera app, take picture, reexit, memory footprint does not go down. 10) Leave idle for several minutes and goes into power save mode. Memory footprint does not go down.

Comment on attachment 8457052 [details] Logs for master/20140716 build Note that the difference between the timestamps in the top log (master.mem.log) and the adb logcat log (master.log) is ~05:24:xx.

Similar to reproduction steps above. Recorded several short videos (<1min) without the issue, however once the preview-going-dark issue was encountered ~1.5 minutes into the final recording, the memory began to spike. After the recording was stopped, the issue remained with just the preview window and the memory footprint could be pushed up then as well (to settle at ~165MB this time).

Note that no memory constraints (i.e. lowering it below 300MB) are in place, like mentioned in a perhaps related bug 1027592. The configuration is left to the default (auto).

Reproduced on latest v2.0 build (20140716000201). STR: 1) Flash device with latest image, started collecting logs on first boot. 2) Start recording first video looking at the plasma gif, moving in and out. 3) Around 1:20 seconds (same as other two reproductions), screen begans to dark for long periods of time. 4) Continued for another few minutes, memory continued to rise. 5) Stop recording, can continue to reproduce in preview. 6) Memory for process peaked at ~340MB, and settled at ~251MB when idle.

Reproduced on v1.4/20140716000201 as well, although step 3 took much longer, ~4 minutes to reach that state.

m1: Would you be able to take a look at some of the logs from the mm-qcamera-daemon perspective? You should be able to narrow down the areas of interest within a few seconds by looking at the *.mem.log files. The memory usage for mm-qcamera-daemon should start to rise very quickly in those areas. Again if the context helps, visually I see the preview window darken to the point all is black, looking at things it previously would display; it recovers after 5-10 seconds normally. Once we get the camera in that state, it is relatively easy to increase the service footprint, including when we aren't recording a video, just displaying the preview. Thanks!

Inder, I'm told m1 is OoO. Can you take a look at this one?

Additional notes: able to reproduce on a flame with the memory reduced to 320MB, although the rapid increase in mm-qcamera-daemon caused the system to start slaying processes and brought it to a halt.

Sure, Tapas will try to reproduce it on our 2.0 QRD (KK based). If the issue turns out to be JB specific then there might be some delay due to current focus on 2.0 FC release. But we will try to get analysis on it asap.

(In reply to Inder from comment #9) > Sure, Tapas will try to reproduce it on our 2.0 QRD (KK based). If the issue > turns out to be JB specific If it's JB specific then I suggest we WONTFIX this bug. Instead the fix would likely be to obtain the KK version of Flame.

I am running camera recording for infinite time on FFOS 2.0 QRD (kk based): here is the procrank data after 10mins camera recording in FFOS 2.0 QRD (kk 3.6 based) : tkundu@tkundu-linux:/net/cros-bs-p3/local/mnt/workspace/tkundu/kkAU32$ adb shell procrank PID Vss Rss Pss Uss cmdline 242 255968K 54280K 50862K 49356K /system/b2g/b2g 1102 98296K 23168K 20827K 20148K /system/b2g/plugin-container 1103 105916K 24336K 16878K 13764K /system/b2g/plugin-container 1005 70156K 14108K 8235K 6460K /system/b2g/plugin-container 285 70276K 11924K 7603K 7564K /system/bin/mm-qcamera-daemon 1411 60180K 13048K 7051K 5160K /system/b2g/plugin-container 934 53940K 9048K 3798K 2220K /system/b2g/plugin-container 228 126884K 7728K 3774K 3152K /system/bin/mediaserver 225 27460K 2152K 1691K 1648K /system/bin/rild 287 23516K 1680K 1347K 1316K /system/bin/mm-pp-daemon 5350 1260K 728K 608K 604K procrank 286 7980K 936K 601K 572K /system/bin/audiod 1022 7048K 876K 585K 572K /system/bin/wpa_supplicant 309 12752K 680K 523K 516K /system/bin/xtwifi-client 1 760K 620K 504K 420K /init 249 25484K 704K 474K 464K /system/bin/thermal-engine 302 14888K 588K 463K 456K /system/bin/xtwifi-inet-agent 288 8000K 708K 460K 448K /system/bin/netmgrd 223 10088K 668K 433K 412K /system/bin/netd 268 11796K 640K 417K 400K /system/bin/qmuxd 275 2472K 544K 403K 396K /system/bin/sdcard 216 4672K 536K 362K 348K /system/bin/vold 280 7576K 556K 308K 288K /system/bin/time_daemon 246 3236K 508K 285K 276K /system/bin/ptt_socket_app 315 5376K 468K 276K 268K /system/bin/lowi-server 254 3648K 500K 271K 256K /system/bin/wcnss_service 243 3476K 504K 271K 252K /system/bin/qcom-system-daemon 188 620K 348K 268K 192K /sbin/ueventd 1052 7284K 416K 225K 216K /system/bin/mpdecision 304 4588K 236K 210K 208K /sbin/adbd 219 2192K 360K 210K 204K /system/bin/rfs_access 298 948K 328K 195K 192K /system/bin/location-mq 300 6768K 348K 188K 184K /system/bin/rmt_storage 241 3284K 364K 152K 128K /system/bin/gonksched 359 6364K 392K 150K 88K /system/bin/qseecomd 332 1064K 296K 148K 144K /system/bin/charger_monitor 214 1432K 148K 144K 144K /sbin/healthd 277 3496K 280K 131K 120K /system/bin/sdcard 278 3496K 280K 129K 116K /system/bin/sdcard 276 2468K 260K 122K 116K /system/bin/sdcard 253 1952K 240K 121K 116K /system/bin/adsprpcd 257 928K 212K 118K 116K /system/bin/sh 282 2172K 332K 112K 48K /system/bin/qseecomd 224 1036K 248K 112K 96K /system/bin/debuggerd 251 924K 244K 111K 108K /system/bin/qrngd 215 1004K 204K 102K 100K /system/bin/servicemanager ------ ------ ------ 132279K 120372K TOTAL RAM: 272960K total, 2912K free, 376K buffers, 27088K cached, 5912K shmem, 25204K slab tkundu@tkundu-linux:/net/cros-bs-p3/local/mnt/workspace/tkundu/kkAU32$ I am not seeing any increase in VSS of mm-qcamera-daemon. I think that this issue is not present on KK device. Please NI on me if you feel I am missing some STR.

Attempted to reproduce on 165 of KK, confirming that it is resolved.