Closed
Bug 1045704
Opened 10 years ago
Closed 7 years ago
[Camera][Flame] After about an hour of recording video, Camera USS goes *insaaaane*
Categories
(Firefox OS Graveyard :: Gaia::Camera, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: mikeh, Unassigned)
Details
Attachments
(1 file)
165.75 KB,
image/png
|
Details |
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
Reporter | ||
Comment 1•10 years ago
|
||
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.1?
Reporter | ||
Comment 2•10 years ago
|
||
(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•10 years ago
|
||
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.
Reporter | ||
Comment 5•10 years ago
|
||
(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.
Flags: needinfo?(mhabicher) → needinfo?(dhylands)
Reporter | ||
Comment 6•10 years ago
|
||
ni? myself to remind me to reproduce this on v165.
Flags: needinfo?(mhabicher)
Comment 7•10 years ago
|
||
(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.
Flags: needinfo?(dhylands)
Comment 8•10 years ago
|
||
Asked Mike to reproduce this. Removing the nomination for 2.1
blocking-b2g: 2.1? → ---
Reporter | ||
Comment 9•7 years ago
|
||
Closing due to the end of the b2g project.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(bugzilla)
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•