1045704 - [Camera][Flame] After about an hour of recording video, Camera USS goes *insaaaane*

Status: RESOLVED INCOMPLETE

(Firefox OS Graveyard :: Gaia::Camera, defect)

Description

[Mike Habicher [:mikeh] (high bugzilla latency)]

Attachment: Camera app/mm-qcamera-daemon plot of USS (MB) vs time (seconds)

I observed this while testing my USS plotter and investigating general memory-leak issues in the camera stack.

In this case, the Camera app USS[1] is stable at just under 20MB for most of the 1-hour video I recorded. However, at around the 57 to 58-minute mark, the reported USS goes crazy, beginning a steady climb up to about 162MB, dragging the mm-qcamera-daemon process' USS erratically along with it, up from 10MB to almost 89MB.

Eventually things start to fluctuate wildly. Video recording continues for approximately another 5 minutes with the exposure fluctuating wildly and the viewfinder getting increasingly janky. The Keyboard and Usage apps are killed, and eventually the Camera app is killed as well.

This happens on a Flame running v123 configured with 512MB of memory.

According to |adb shell cat /proc/<pid>/smaps| most of the memory is held in "anon:jemalloc":

a5e00000-af400000 rw-p 00000000 00:00 0          [anon:jemalloc]
Size:             153600 kB
Rss:              146252 kB
Pss:              146252 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:    146252 kB
Referenced:        65144 kB
Anonymous:        146252 kB
AnonHugePages:         0 kB
Swap:               7316 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Locked:                0 kB

1. http://elinux.org/Android_Memory_Usage

Comment 1

[Mike Habicher [:mikeh] (high bugzilla latency)]

[Blocking Requested - why for this release]:

Comment 2

[Mike Habicher [:mikeh] (high bugzilla latency)]

(In reply to Mike Habicher [:mikeh] from comment #1)

> [Blocking Requested - why for this release]: prioritization.

This should be investigated to determine:
- if it happens on v162-3 (KitKat)
- if it happens on lower memory configurations of flame

Comment 3

[Dave Hylands [:dhylands]]

Is it possible that we're generating data faster than it can be written to flash/sd?

And what happens around the on hour mark is that c

It would be interesting to see some of the numbers from /proc/meminfo (Free/Cached/Swap) over time while this is happening.

Comment 4

[Sri Kasetti]

NI Mike H

Comment 5

[Mike Habicher [:mikeh] (high bugzilla latency)]

(In reply to Dave Hylands [:dhylands] from comment #3)

> Is it possible that we're generating data faster than it can be written to flash/sd?

If that were happening, I would expect to see a gradual increase in USS over the course of the video being recording.

> And what happens around the on hour mark is that c

?

> It would be interesting to see some of the numbers from /proc/meminfo
> (Free/Cached/Swap) over time while this is happening.

Assuming I can reproduce this issue, those should be easy enough to get.

Comment 6

[Mike Habicher [:mikeh] (high bugzilla latency)]

ni? myself to remind me to reproduce this on v165.

Comment 7

[Dave Hylands [:dhylands]]

(In reply to Mike Habicher [:mikeh] from comment #5)
> (In reply to Dave Hylands [:dhylands] from comment #3)
> 
> > Is it possible that we're generating data faster than it can be written to flash/sd?
> 
> If that were happening, I would expect to see a gradual increase in USS over
> the course of the video being recording.

Not necessarily. If the cache has available space, then the data would get written to the cache. But if there is no more system memory, then the write would become blocked, and then things would start backing up within the process.

> > And what happens around the on hour mark is that c
> 
> ?

I think I was trying to say that maybe the cache became full.

Comment 8

[Sri Kasetti]

Asked Mike to reproduce this. Removing the nomination for 2.1

Comment 9

[Mike Habicher [:mikeh] (high bugzilla latency)]

Closing due to the end of the b2g project.