Closed
Bug 1039654
Opened 10 years ago
Closed 10 years ago
[B2G][Camera][Flame] mm-qcamera-daemon memory spikes during recording and does not recover
Categories
(Firefox OS Graveyard :: Gaia::Camera, defect)
Tracking
(b2g-v1.4 affected, b2g-v2.0 affected, b2g-v2.1 affected)
RESOLVED
WORKSFORME
People
(Reporter: aosmond, Unassigned)
Details
Attachments
(4 files)
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.
Reporter | ||
Updated•10 years ago
|
status-b2g-v2.1:
--- → affected
Reporter | ||
Comment 1•10 years ago
|
||
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.
Attachment #8457052 -
Attachment description: master.memleak.tar.gz → Logs for master/20140716 build
Reporter | ||
Comment 2•10 years ago
|
||
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).
Reporter | ||
Comment 3•10 years ago
|
||
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).
Reporter | ||
Comment 4•10 years ago
|
||
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.
Reporter | ||
Updated•10 years ago
|
status-b2g-v2.0:
--- → affected
Reporter | ||
Comment 5•10 years ago
|
||
Reproduced on v1.4/20140716000201 as well, although step 3 took much longer, ~4 minutes to reach that state.
Reporter | ||
Updated•10 years ago
|
status-b2g-v1.4:
--- → affected
Reporter | ||
Comment 6•10 years ago
|
||
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!
Flags: needinfo?(mvines)
Comment 7•10 years ago
|
||
Inder, I'm told m1 is OoO. Can you take a look at this one?
Flags: needinfo?(ikumar)
Reporter | ||
Comment 8•10 years ago
|
||
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.
Flags: needinfo?(mvines)
Flags: needinfo?(ikumar)
Comment 10•10 years ago
|
||
(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.
Flags: needinfo?(aosmond)
Reporter | ||
Comment 12•10 years ago
|
||
Attempted to reproduce on 165 of KK, confirming that it is resolved.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(aosmond)
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•