Closed Bug 1059144 Opened 10 years ago Closed 10 years ago

[MADAI][Multimedia] System crash when RTSP client connects to a non-RTSP-server port

Categories

(Firefox OS Graveyard :: RTSP, defect)

defect
Not set
normal

Tracking

(blocking-b2g:2.0M+, b2g-v2.0 fixed, b2g-v2.0M fixed, b2g-v2.1 fixed, b2g-v2.1S fixed, b2g-v2.2 verified, b2g-v2.5 verified, b2g-master verified)

VERIFIED FIXED
2.1 S2 (15aug)
blocking-b2g 2.0M+
Tracking Status
b2g-v2.0 --- fixed
b2g-v2.0M --- fixed
b2g-v2.1 --- fixed
b2g-v2.1S --- fixed
b2g-v2.2 --- verified
b2g-v2.5 --- verified
b2g-master --- verified

People

(Reporter: jaemin1.song, Assigned: ethan)

References

Details

(Whiteboard: [LibGLA,TD91891,WW,A] [p=2])

Attachments

(2 files, 2 obsolete files)

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36

Steps to reproduce:

I have found reboot symptom using below link.
Link: rtsp://125.141.31.186:81/Tellme.wmv


Actual results:

As you know, FireFox OS does not support this link's type.
If I try to play the link, browser should pop-up "unsupported type" message.
But when I try to play the link, device is occurred reboot symptom.
When symptom is occurred, I have found below error log.

gecko/netwerk/protocol/rtsp/rtsp/ARTSPConnection.cpp:655 CHECK(IsRTSPVersion( AString( response->mStatusLine, space2 + 1, response->mStatusLine.size() - space2 - 1))) failed. 

Reproducible rate: 100%Please confirm this issue with above link.

Thanks.
Dear Ethan,

I have created another reboot symptom issue.
Please confirm it.
Component: General → RTSP
Flags: needinfo?(ettseng)
Whiteboard: [LibGLA,TD91891,WW,A]
Jaemin,

Thanks for filing this bug.
I can reproduce it and I'll fix the problem.
Assignee: nobody → ettseng
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(ettseng)
Whiteboard: [LibGLA,TD91891,WW,A] → [LibGLA,TD91891,WW,A] [p=2]
Target Milestone: --- → 2.1 S2 (15aug)
Is port 81 on 125.141.31.186 listened by an HTTP server?
From captured packets, I see this IP replies "HTTP/1.1 400 Bad Request".
(In reply to Ethan Tseng [:ethan] from comment #3)
> Is port 81 on 125.141.31.186 listened by an HTTP server?
> From captured packets, I see this IP replies "HTTP/1.1 400 Bad Request".

I don't know about server status.
In my opinion, 
port 81 on 125.141.31.186 is listened by an HTTP server.

Thanks.
Modified the title to describe the bug more precisely.
Summary: [MADAI][Multimedia] When I try to play link(RTSP unsupported link), detected reboot symptom. → [MADAI][Multimedia] System crash when RTSP client connects to a non-RTSP-server port
Simply replace a CHECK() assertion by a normal check.
Attachment #8480434 - Flags: review?(sworkman)
Remove an unintentional code change (in moz.build).
Attachment #8480434 - Attachment is obsolete: true
Attachment #8480434 - Flags: review?(sworkman)
Attachment #8480436 - Flags: review?(sworkman)
Hi Steve,
This is a minor change. Could you review it?

The crash happens when RTSP client connects to a certain port which is listened by a non-RTSP server.
For example, an HTTP server might respond:
"HTTP/1.1 400 Bad Request", or "HTTP/1.1 501 Method Not Implemented".

We should gracefully shutdown the client if the received packet is not a valid RTSP request or response.
BTW, we had discussed the idea to replace all of these CHECK() assertions by graceful error handle.
https://bugzilla.mozilla.org/show_bug.cgi?id=1038037#c25
Bug 1045062 was filed to fix this.

Such assertions were hit several times recently.
I think we should prioritize bug 1045062 to avoid potential system crashes.
Attachment #8480436 - Attachment description: Avoid crash from invalid RTSP response → Avoid crash caused by invalid RTSP response
Attached file gdb_backtrace.log
GDB backtrace output.
Attachment #8480436 - Flags: review?(sworkman) → review+
Refresh comment "r=sworkman".
Attachment #8480436 - Attachment is obsolete: true
The result of Try server:
https://tbpl.mozilla.org/?tree=Try&rev=89d05d591b1b
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/09b7bd9254d5
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Hi Kai-Zhen,
Could you help to land this on 2.0M? Thanks!
Blocks: Woodduck
blocking-b2g: --- → 2.0M+
Flags: needinfo?(kli)
Comment on attachment 8481189 [details] [diff] [review]
Avoid crash caused by invalid RTSP response

Request to uplift to 2.0.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): None
User impact if declined: Potential device crash (reboot)
Testing completed: On m-c
Risk to taking this patch (and alternatives if risky): None
String or UUID changes made by this patch: None
Attachment #8481189 - Flags: approval-mozilla-b2g32?
(In reply to Ethan Tseng [:ethan] from comment #17)
> Request to uplift to 2.0.

This bug was resolved in most current releases except v2.0.
Raise uplift request because we encountered this bug while dealing with a 2.0M blocker (bug 1117486) recently. Landing the patch to 2.0 could reduce the change of device crash.
Comment on attachment 8481189 [details] [diff] [review]
Avoid crash caused by invalid RTSP response

looks low risk and helps with stability, so approving.
Attachment #8481189 - Flags: approval-mozilla-b2g32? → approval-mozilla-b2g32+
(In reply to Ethan Tseng [:ethan] from comment #18)
> 2.0M blocker (bug 1117486) recently. Landing the patch to 2.0 could reduce
> the change of device crash.
Typo: Landing the patch to 2.0 could reduce the "chance" of device crash.


(In reply to bhavana bajaj [:bajaj] from comment #19)
> looks low risk and helps with stability, so approving.
Thank you, Bhavana! :)
This issue is verified fixed on Flame and Aries. Using browser to access the URL at comment 0, I did not see a system reboot or crash. It opened up a page with a supposedly media player with empty content but an error message in there saying 'Video playback aborted due to a network error', and the thin blue-colored loading bar never finished loading, which seems odd.

Verified on:
Device: Flame 2.6
BuildID: 20151209030343
Gaia: 961528f4391668bc89ec0be14fa367cea099b588
Gecko: 319be5e7ce3061c7c16f24d750b6dacdbcac4c35
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 45.0a1 (2.6) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

Device: Aries 2.6
BuildID: 20151209121803
Gaia: 961528f4391668bc89ec0be14fa367cea099b588
Gecko: 319be5e7ce3061c7c16f24d750b6dacdbcac4c35
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 45.0a1 (2.6) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

Device: Flame 2.5
BuildID: 20151208120554
Gaia: 2d54c29f429bed790b5d8284633812dc2b782518
Gecko: ff31a251b2f6149edf4fc0a199133ef2e190ceac
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 44.0a2 (2.5) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Device: Flame 2.2
BuildID: 20151209032501
Gaia: 885647d92208fb67574ced44004ab2f29d23cb45
Gecko: 4381c4b69b9c
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: