New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 627624 link

Starred by 53 users

Issue metadata

Status: Duplicate
Merged: issue 660738
Owner:
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

apprtc peer2peer call froze after a few mins

Project Member Reported by srnarayanan@chromium.org, Jul 12 2016

Issue description

Version: Version: M53 Dev 53.0.2785.9 
OS: Sailfish device, Android version NMR1

What steps will reproduce the problem?
(1) Start a Peer2Peer call
(2) Open a new tab and browse to http://192.168.1.1
test case under execution: https://testtracker.googleplex.com/testplans/testcase/detail/168011?id=3443&revision=1

What is the expected output?
The call should not freeze and I should be able to apply packet loss 

What do you see instead?
The call froze.

Please use labels and text to provide additional information.
Logs attached 
 
logs.txt
1.5 MB View Download
Could you pinpoint a time? The logcat log contains from the whole OS and is over 1 hour long so it's really hard to pinpoint where the issue could be.
Owner: srnarayanan@chromium.org
Status: Assigned (was: Untriaged)
Labels: webrtc-new-device
Project Member

Comment 4 by sheriffbot@chromium.org, Jul 13 2016

Labels: -M-53 M-54 MovedFrom-53
Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: WontFix (was: Assigned)
Hmm, I don't recollect at what time I ran this test, and now I'm not able to reproduce this with multiple fresh calls.

Closing this as Won't Fix for now .. will reopen if I encounter this again.
Then it could have been a network issue.
I'm able to reproduce this now .. filing an equivalent buganizer issue for this 

Logs - https://x20web.corp.google.com/~srnarayanan/no_crawl/crbug627624/logs16.txt
Status: Unconfirmed (was: WontFix)
Reopening per c#7.
I see tons of these:

07-21 11:11:30.516 W/Thread-4(10973): type=1400 audit(0.0:5180): avc: denied { ioctl } for path="socket:[225248]" dev="sockfs" ino=225248 ioctlcmd=8b1b scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:r:untrusted_app:s0:c512,c768 tclass=udp_socket permissive=0

Not sure if it's related.

Could you file a buganizer bug for this?
jansson@ - already filed one https://buganizer.corp.google.com/u/0/issues/30281614
Owner: braveyao@chromium.org
Status: Assigned (was: Unconfirmed)
Thanks! Assigning to braveyao@ since he's the owner of the buganizer bug as well.
Cc: niklase@chromium.org
Labels: -Pri-3 -M-54 ReleaseBlock-Stable M-53 Pri-1
Marking as Pri-1 RB-Stable to match b/ bug.  Copying some data from b/ as well:

---

Had some tests on Sailfish/Marlin and failed to get any consistent result. Some observations:
- This problem may happen at joining the room or at tab switching or no-replication. So far it's hard to say switching tab is the trigger condition.

- This problem may happen with different symptoms and error logs.
  Either local preview will also freeze (Camera service failure) with logs: 
===================================================
07-26 14:33:23.681  3902  4808 E BufferQueueProducer: [ImageReader-640x480f23m2-3902-1] dequeueBuffer: BufferQueue has been abandoned
07-26 14:33:23.682  3902  4339 E BufferQueueProducer: [ImageReader-640x480f23m2-3902-1] queueBuffer: BufferQueue has been abandoned
07-26 14:33:23.682   555  4705 E Camera3-OutputStream: getBufferLocked: Stream 0: Can't dequeue next output buffer: No such device (-19)
07-26 14:33:23.682   555  4705 E Camera3-Device: RequestThread: Can't get output buffer, skipping request: No such device (-19)
07-26 14:33:23.682   555  4716 E Surface : queueBuffer: error queuing buffer to SurfaceTexture, -19
07-26 14:33:23.683   555  4716 E Camera3-OutputStream: returnBufferCheckedLocked: Stream 0: Error queueing buffer to native window: No such device (-19)
07-26 14:33:23.683   555  4716 E Camera3-Device: Can't return buffer to its stream: No such device (-19)
07-26 14:33:23.782  3902  3915 E BufferQueueProducer: [ImageReader-640x480f23m2-3902-1] queueBuffer: BufferQueue has been abandoned
07-26 14:33:23.782   555  4716 E Surface : queueBuffer: error queuing buffer to SurfaceTexture, -19
07-26 14:33:23.782   555  4716 E Camera3-OutputStream: returnBufferCheckedLocked: Stream 0: Error queueing buffer to native window: No such device (-19)
========================================================

  Or local preview works and no more outbound video stream (Time failure?) with logs:
========================================================
7-26 16:23:04.675 15701 15799 W chromium: [WARNING:video_capture_input.cc(79)] Same/old NTP timestamp (3678564097510 <= 3678564168167) for incoming frame. Dropping.
07-26 16:23:04.708 15701 15799 W chromium: [WARNING:video_capture_input.cc(79)] Same/old NTP timestamp (3678564097541 <= 3678564168167) for incoming frame. Dropping.
=========================================================

- This problem is also seen on Nexus5 with M. Haven't got a change to have a closer look.

- May not be related: Sailfish/Marlin is very hot during testing...
=========================================================
07-26 16:23:04.771   547   671 I ThermalEngine: vs_get_temperature: read[0] tsens_tz_sensor15 56000 mC, weight[0] 1
07-26 16:23:04.771   547   671 I ThermalEngine: vs_get_temperature: read[1] tsens_tz_sensor0 59000 mC, weight[1] -1
=========================================================

Need to do more tests before any conclusion can be drawn.

---

Setting as RB-Stable for M53 given niklase@'s concern on the b/ bug.

Also re: c#9 above - I have closed the associated b/ bug since to this point it looks like we should track this as a Chrome issue.  However, if we should be tracking the issue re: those entries in the logs, please re-open the b/ bug (but be sure to repurpose it for that issue specifically) or file a new b/ bug.
some updates:

The problem should start from M52. So far I didn't see any problem in M51. And it hits other devices, for example Nexus5 with Android L&M.
The major reason is this one:
===================================================
07-26 14:33:23.681  3902  4808 E BufferQueueProducer: [ImageReader-640x480f23m2-3902-1] dequeueBuffer: BufferQueue has been abandoned
07-26 14:33:23.682  3902  4339 E BufferQueueProducer: [ImageReader-640x480f23m2-3902-1] queueBuffer: BufferQueue has been abandoned
07-26 14:33:23.682   555  4705 E Camera3-OutputStream: getBufferLocked: Stream 0: Can't dequeue next output buffer: No such device (-19)
07-26 14:33:23.682   555  4705 E Camera3-Device: RequestThread: Can't get output buffer, skipping request: No such device (-19)
07-26 14:33:23.682   555  4716 E Surface : queueBuffer: error queuing buffer to SurfaceTexture, -19
07-26 14:33:23.683   555  4716 E Camera3-OutputStream: returnBufferCheckedLocked: Stream 0: Error queueing buffer to native window: No such device (-19)
07-26 14:33:23.683   555  4716 E Camera3-Device: Can't return buffer to its stream: No such device (-19)
07-26 14:33:23.782  3902  3915 E BufferQueueProducer: [ImageReader-640x480f23m2-3902-1] queueBuffer: BufferQueue has been abandoned
07-26 14:33:23.782   555  4716 E Surface : queueBuffer: error queuing buffer to SurfaceTexture, -19
07-26 14:33:23.782   555  4716 E Camera3-OutputStream: returnBufferCheckedLocked: Stream 0: Error queueing buffer to native window: No such device (-19)
========================================================
When it happens, local preview and remote view at peer will both freeze.
It actually has nothing to do with tab switch. For example, if the second tab shows a simple page, such as google.com, it won't(or hardly) reproduce. Also it may happen when you firstly open the camera at joining the room.
It's more easy to reproduce if the second tab renders a complex page, such as cnn.com.
I guess the main criteria is high CPU load with multiple heavy loaded processes. And process/thread scheduling under such circumstance may cause the camera service of Android out of work.

By manual bisecting, I narrowed down to a kinda "suspicious" revision, which actually doesn't look like a culprit at all. Will try more to verify it.  
Cc: braveyao@chromium.org
Owner: mcasas@chromium.org
The reproduction is too random. But finally I believe the offending cl should be #392397 (Review-Url: https://codereview.chromium.org/1957733003).
Given the fact that it's very hard to reproduce with early M52 versions and more easy with M53/54, maybe the later changes will make the situation more severer.

mcasas@, please take a look.
Owner: niklase@chromium.org
Status: Untriaged (was: Assigned)
#14: the CL was a cleanup and has been landed for 2 months
and 3 weeks without any similar issue being reported AFAIK.
Also, what does it mean that is "easier to reproduce with
M53/54" than "with early M52 versions"? That seems to span 
more than a single CL. Also, I understand from the description 
of the bug, that this is happening in an unreleased device? 
(sailfish?) niklase@ please retriage this bug appropriately.
I've spent hours on these two revisions, #392397 and #392396. No replication with 392396(and earlier) and it happens since 392397. 
And it also happens to Nexus5(M & L).
Owner: mcasas@chromium.org
Status: Assigned (was: Untriaged)
Brave's description might sound confusing but it's correct:

- Without this CL the problem doesn't occur.
- The likelyhood of this problem to be triggered goes up for later Chrome versions - yhat's probably why it wasn't discovered until now.
- It was discovered on Sailfish but also happens on other devices.
Labels: -Pri-1 -ReleaseBlock-Stable Pri-2
What do we know about this bug, really? In which devices
does it repro consistently? What are the concrete steps 
for reproduction? The original description is vague and
comments #14, 16 and #17 essentially only states that it
"occurs". Where is the `adb logcat` during the freeze?
With all that, I don't see evidence enough for making
this a blocker, or for having Pri1 either, so lowering.
Cc: acindhe@chromium.org
 Issue 660738  has been merged into this issue.
Seems  issue 660738  provides some simpler replication methods.
Cc: fbeaufort@chromium.org mlamouri@chromium.org mcasas@chromium.org
 Issue 673397  has been merged into this issue.
Labels: -Restrict-View-Google
Mergedinto: 660738
Status: Duplicate (was: Assigned)
This bug doesn't need to be private anymore since
Sailfish devices are public now.

Sign in to add a comment