1118652 - [FFOS7715 v2.1] [flame & dolphin][video] Playing some RTSP video, system crash.

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: RTSP, defect, P1)

Description

[[e-mail]]

DEFECT DESCRIPTION:
  Playing RTSP video, system crash.

Steps to reproduce:
----------------------------------------------------
1.open the website "114.30.40.60：8800"
2.select "index.html"
3.select "video streaming test", click the some RTSP video to play.
4.system just crash.

Additional info:
--------------------------------------
Reproduce rate: 
 1/10

Comment 1

[[e-mail]]

Dear Ethan:

Comment 2

[[e-mail]]

Dear Ethan:

In log files, I find the same error in bug 1110663.

01-07 14:31:16.422   131  1048 F         : ../../../../gecko/netwerk/protocol/rtsp/rtsp/RTSPConnectionHandler.h:1110 CHECK(mSeekPending) failed.


01-07 14:31:16.912   113   113 I ServiceManager: service 'media.audio_flinger' died
01-07 14:31:16.912   113   113 I ServiceManager: service 'media.player' died
01-07 14:31:16.912   113   113 I ServiceManager: service 'media.camera' died
01-07 14:31:16.912   113   113 I ServiceManager: service 'media.audio_policy' died
01-07 14:31:17.362  1071  1071 I mediaserver: ServiceManager: 0xb7ff5460
01-07 14:31:17.362  1071  1071 I AudioFlinger: Using default 3000 mSec as standby time.

Please help to check this issue.

Thanks!

Comment 3

[Ethan Tseng [:ethan]]

(In reply to [e-mail] from comment #2)
> In log files, I find the same error in bug 1110663.
> 01-07 14:31:16.422   131  1048 F         :
> ../../../../gecko/netwerk/protocol/rtsp/rtsp/RTSPConnectionHandler.h:1110
> CHECK(mSeekPending) failed.

This CHECK() seems to be a real assertion to me.
mSeekPending should always be true here if our code logic is correct.

Jonathan, could you help to look into this?

Comment 4

[Ethan Tseng [:ethan]]

BTW, The crash happens in codes around seeking.
Lin, did you drag the control bar to perform seek operation?
I don't see this step in your STR.

Comment 5

[Jonathan Hao (inactive) [:jhao]]

Hi Lin Hui,

I've been testing your links, and haven't encountered crashing yet. I can't open file sample.mp3 and sample_300kbit.mov but I can't on Linux VLC player either.

Does the system crash immediately or after playing for a while?
Are you testing on 2.1?

Thanks.

Comment 6

[[e-mail]]

(In reply to Ethan Tseng [:ethan] from comment #4)
> BTW, The crash happens in codes around seeking.
> Lin, did you drag the control bar to perform seek operation?
> I don't see this step in your STR.

In wifi condition, the RTSP video cannot playing fluent, sometimes it's showing the spinner, they seeking by itself.

I will upload a attachments to you to find the RTSP video which cause the crash.

Comment 7

[[e-mail]]

Attachment: step_to_repro.docx

Comment 8

[[e-mail]]

Attachment: h263_256k_aac_32k_10f_QVGA.3gp

I downloaded that RTSP video, and playing it in video app, it working fine.

Comment 9

[[e-mail]]

(In reply to Jonathan Hao [:jhao] from comment #5)
> Does the system crash immediately or after playing for a while?
This video only can playing a little while，both in FFOS7715 v2.1 & flame, then skip to the end of the time.
> Are you testing on 2.1?
I‘m ensure on 2.1.

Comment 10

[[e-mail]]

Attachment: flame_crash.jpg

flame also crash when playing that video.

Comment 11

[Jonathan Hao (inactive) [:jhao]]

I'm sorry. I've tried many times, but I can't reproduce in Flame 2.1 with latest PVT build.

Perhaps I should test in a bad wifi condition?

Comment 12

[Peipei Cheng (needinfo if you need my action)]

lin.hui, could you please select send report and attach the crash report here next time you encounter the crash?

Comment 13

[[e-mail]]

(In reply to Peipei Cheng from comment #12)
> lin.hui, could you please select send report and attach the crash report
> here next time you encounter the crash?

When I encounter the crash, I always select send report.

Comment 14

[Peipei Cheng (needinfo if you need my action)]

(In reply to [e-mail] from comment #13)
> (In reply to Peipei Cheng from comment #12)
> > lin.hui, could you please select send report and attach the crash report
> > here next time you encounter the crash?
> 
> When I encounter the crash, I always select send report.

after you send the report, can you run following command to get the latest submitted crash id? 

adb root
adb shell
ls -l /data/b2g/mozilla/Crash Reports/submitted

Comment 15

[[e-mail]]

(In reply to Peipei Cheng from comment #14)
> (In reply to [e-mail] from comment #13)
> > (In reply to Peipei Cheng from comment #12)
> > > lin.hui, could you please select send report and attach the crash report
> > > here next time you encounter the crash?
> > 
> > When I encounter the crash, I always select send report.
> 
> after you send the report, can you run following command to get the latest
> submitted crash id? 
> 
> adb root
> adb shell
> ls -l /data/b2g/mozilla/Crash Reports/submitted

Just now，when playing that RTSP video, flame crashed， I got all the crash ID from yesterday to today：

Crash ID: bp-75f28c52-e56d-4806-a5fe-d001d2150107

Crash ID: bp-efb793c4-1037-4336-999a-6559b2150107

Crash ID: bp-b61a7f83-038a-4974-8851-ca9912150108

in addition, the flame in a single nucleus condition.

Comment 16

[Peipei Cheng (needinfo if you need my action)]

 Jonathan, could you please help check the crash report mentioned in comment 15?

Comment 17

[Jonathan Hao (inactive) [:jhao]]

CC John

John has identified a problem of Audio Resource in Spreadtrum similar to that in the crash report. This still doesn't explain the crash in Flame, though.

Comment 18

[[e-mail]]

Today, I found a new crash on flame 2.1：
Crash ID: bp-5c800d43-a448-4ecd-b141-b300f2150109

Please help to check this.

Comment 19

[John Lin [:jhlin][:jolin]]

(In reply to [e-mail] from comment #18)
> Today, I found a new crash on flame 2.1：
> Crash ID: bp-5c800d43-a448-4ecd-b141-b300f2150109
> 
> Please help to check this.

 Could you please help check (or upload) the logcat output before crashing? The problem mentioned in comment 17 should say something like "[...] called start in the unexpected state: ..." in logcat. Thanks.

Comment 20

[[e-mail]]

(In reply to John Lin [:jolin][:jhlin] from comment #19)
>  Could you please help check (or upload) the logcat output before crashing?
> The problem mentioned in comment 17 should say something like "[...] called
> start in the unexpected state: ..." in logcat. Thanks.
I'm so sorry, I'll upload the logcat output next time when I find a crash.

Dear Ethan:
According to bug 1110663 and bug 1045062, can we using the same way to replace CHECK assertions by NS_ASSERTION or graceful assertions to avoid this crash when playing RTSP video?

Comment 21

[Ethan Tseng [:ethan]]

(In reply to [e-mail] from comment #20)
> Dear Ethan:
> According to bug 1110663 and bug 1045062, can we using the same way to
> replace CHECK assertions by NS_ASSERTION or graceful assertions to avoid
> this crash when playing RTSP video?

Before doing this, we must be sure which CHECK() assertion causes the crash.
Furthermore, some crashes in your crash reports do not have CHECK() assertion.
For example,
Crash ID: bp-75f28c52-e56d-4806-a5fe-d001d2150107
This crash occurs at the line |err = mAudioSource->read(&mAudioBuffer);|.
It seems to be accessing a null pointer.

I think we still have to find out concrete steps-to-reproduce before fixing it.

Comment 22

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Per discussion with partner, close this one since we cannot reproduce this any more