Issue metadata
Sign in to add a comment
|
apprtc peer2peer call froze after a few mins |
||||||||||||||||||||||||
Issue descriptionVersion: 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
,
Jul 13 2016
,
Jul 13 2016
,
Jul 13 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 13 2016
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.
,
Jul 14 2016
Then it could have been a network issue.
,
Jul 21 2016
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
,
Jul 25 2016
Reopening per c#7.
,
Jul 26 2016
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?
,
Jul 26 2016
jansson@ - already filed one https://buganizer.corp.google.com/u/0/issues/30281614
,
Jul 27 2016
Thanks! Assigning to braveyao@ since he's the owner of the buganizer bug as well.
,
Jul 29 2016
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.
,
Jul 30 2016
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.
,
Aug 1 2016
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.
,
Aug 2 2016
#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.
,
Aug 2 2016
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).
,
Aug 2 2016
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.
,
Aug 15 2016
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.
,
Dec 19 2016
,
Dec 19 2016
Seems issue 660738 provides some simpler replication methods.
,
Jan 9 2017
Issue 673397 has been merged into this issue.
,
Jan 17 2017
This bug doesn't need to be private anymore since Sailfish devices are public now. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by jansson@chromium.org
, Jul 13 2016