Closed Bug 1058022 Opened 6 years ago Closed 6 years ago

B2G crashes during RTSP and HTTP streaming playback

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
critical

Tracking

(blocking-b2g:2.0+, firefox33 wontfix, firefox34 fixed, firefox35 fixed, b2g-v2.0 fixed, b2g-v2.0M fixed, b2g-v2.1 fixed, b2g-v2.2 fixed)

RESOLVED FIXED
2.1 S5 (26sep)
blocking-b2g 2.0+
Tracking Status
firefox33 --- wontfix
firefox34 --- fixed
firefox35 --- fixed
b2g-v2.0 --- fixed
b2g-v2.0M --- fixed
b2g-v2.1 --- fixed
b2g-v2.2 --- fixed

People

(Reporter: poojas, Assigned: hchang)

References

Details

(Keywords: crash, Whiteboard: [caf-crash 325][caf priority: p2][b2g-crash][CR 712723])

Crash Data

Attachments

(4 files, 4 obsolete files)

Attached file Crash dump
B2G OS crashed during HTTP and RTSP streaming playback.
While playing 1 RTSP and 1 HTTP url , one after another, after 90 iterations B2G crashes

Crash signature:

Thread 89 (crashed)
 0  libnss3.so!PR_GetIdentitiesLayer [prlayer.c : 721 + 0x0]
     r0 = 0x5a5a5a5a    r1 = 0x00000000    r2 = 0x00000000    r3 = 0x11111111
     r4 = 0x00000000    r5 = 0x00000000    r6 = 0xaab1c430    r7 = 0x00000000
     r8 = 0x00000000    r9 = 0xaab1c430   r10 = 0xa58ffaa8   r12 = 0x00000002
     fp = 0xffffffff    sp = 0xa58ffa80    lr = 0xb6549907    pc = 0xb653b5a6
    Found by: given as instruction pointer in context
 1  libnss3.so!_pr_poll_with_poll [ptio.c : 3848 + 0xd]
     r4 = 0x00000000    r5 = 0x00000000    r6 = 0xaab1c430    r7 = 0x00000000
     r8 = 0x00000000    r9 = 0xaab1c430   r10 = 0xa58ffaa8    fp = 0xffffffff
     sp = 0xa58ffa80    pc = 0xb6549907
    Found by: call frame info
 2  libxul.so!android::ARTPConnection::onPollStreams() [ARTPConnection.cpp : 313 + 0x11]
     r4 = 0x00000002    r5 = 0x00000002    r6 = 0xaab1c430    r7 = 0x00000002
     r8 = 0xaaa7ae50    r9 = 0xaab1c430   r10 = 0xaab29b20    fp = 0xb6f172ec
     sp = 0xa58ffcd0    pc = 0xb4b2ba9f
    Found by: call frame info
 3  libstagefright_foundation.so!android::ALooperRoster::deliverMessage(android::sp<android::AMessage> const&) [ALooperRoster.cpp : 148 + 0x7]
     r4 = 0xa58ffd60    r5 = 0xaaa7ae50    r6 = 0x00000004    r7 = 0xb6b11024
     r8 = 0xb6e2c559    r9 = 0xa5802000   r10 = 0xbef0b14c    fp = 0xb6f172ec
     sp = 0xa58ffd20    pc = 0xb6b09437
    Found by: call frame info
 4  libstagefright_foundation.so!android::ALooper::loop() [ALooper.cpp : 213 + 0x5]
     r4 = 0x00000001    r5 = 0xa58ffd60    r6 = 0xaaa7ad30    r7 = 0xaa968a0c
     r8 = 0xb6e2c559    r9 = 0xa5802000   r10 = 0xbef0b14c    fp = 0xb6f172ec
     sp = 0xa58ffd48    pc = 0xb6b08f13
    Found by: call frame info
 5  libutils.so!android::Thread::_threadLoop(void*) [Threads.cpp : 770 + 0x7]
     r4 = 0xaa968a00    r5 = 0xa58ffd78    r6 = 0xb6b109ec    r7 = 0xaa968a0c
     r8 = 0xb6e2c559    r9 = 0xa5802000   r10 = 0xbef0b14c    fp = 0xb6f172ec
     sp = 0xa58ffd78    pc = 0xb6e2c9ef
    Found by: call frame info
 6  libutils.so!thread_data_t::trampoline(thread_data_t const*) [Threads.cpp : 95 + 0x3]
     r4 = 0xab1363e0    r5 = 0xffffffec    r6 = 0xb6e2c985    r7 = 0xaa968a00
     r8 = 0xb6e2c559    r9 = 0xa5802000   r10 = 0xbef0b14c    fp = 0xb6f172ec
     sp = 0xa58ffda0    pc = 0xb6e2c591
    Found by: call frame info
 7  libc.so!__thread_entry [pthread_create.cpp : 105 + 0x6]
     r3 = 0x00000000    r4 = 0xa58ffdd0    r5 = 0x00881588    r6 = 0xb6e2c559
     r7 = 0xab1361f0    r8 = 0xb6e2c559    r9 = 0xa5802000   r10 = 0xbef0b14c
     fp = 0xb6f172ec    sp = 0xa58ffdb8    pc = 0xb6ed822c
    Found by: call frame info
 8  libc.so!pthread_create [pthread_create.cpp : 224 + 0x16]
     r3 = 0xab1361f0    r4 = 0x00881588    r5 = 0xa58ffdd0    r6 = 0x00000000
     r7 = 0x00000078    r8 = 0xb6e2c559    r9 = 0xa5802000   r10 = 0xbef0b14c
     fp = 0xb6f172ec    sp = 0xa58ffdd0    pc = 0xb6ed83c4
    Found by: call frame info
 9  0xa2a42472
     r4 = 0x00000000    r5 = 0x00000000    r6 = 0x583fac4f    r7 = 0x00000000
     r8 = 0x00000000    r9 = 0x00000000   r10 = 0x00000000    fp = 0x00000000
     sp = 0xa58ffe00    pc = 0xa2a42474
    Found by: call frame info

------

Laos find detailed attached crash

Target QRD 8x26
"gaia" revision="de28796a8956a48bb98ca67df6a33e0622d642d1"
"gecko" revision="2b27becae85092d46bfadcd4fb5605e82e1e1093"
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.0?
Whiteboard: [b2g-crash][CR 712723]
Whiteboard: [b2g-crash][CR 712723] → [caf priority: p1][b2g-crash][CR 712723]
Whiteboard: [caf priority: p1][b2g-crash][CR 712723] → [caf-crash 325][caf priority: p1][b2g-crash][CR 712723]
Keywords: crash
Observed on: 

Device: msm8226
Gonk Version: AU_LINUX_GECKO_B2G_KK_3.6.01.04.00.000.066
Moz BuildID: 20140810160202
B2G Version: 2.0
Gecko Version: 32.0
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=de28796a8956a48bb98ca67df6a33e0622d642d1
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=2b27becae85092d46bfadcd4fb5605e82e1e1093
Component: Stability → Video/Audio
Product: Firefox OS → Core
Version: unspecified → 32 Branch
Component: Video/Audio → RTSP
Product: Core → Firefox OS
Version: 32 Branch → unspecified
Waiting for more information from CAF on them testing this with latest gecko/gaia cset before blocking here.
(In reply to bhavana bajaj [:bajaj] from comment #3)
> Waiting for more information from CAF on them testing this with latest
> gecko/gaia cset before blocking here.

Do we know if there are changes to the code base where the crash is seen, before proceeding ahead with the testing?
Ethen, can we get any clue form description?
Flags: needinfo?(ettseng)
This bug seems hard to reproduce. The only clue is it crashed at "ARTPConnection.cpp : 313".
I'll look at codes around here to see if anything is suspicious.

Meanwhile, Pooja, could you provide more input?
What HTTP and RTSP links did you use?
Were you connecting to public servers or local servers set up on your own?
Could you describe the step in more detail? Such as, what you mean "one after another"?
Did you press back and click another link? Or you press the URL bar and click a history link?
Flags: needinfo?(ettseng) → needinfo?(poojas)
(In reply to Ethan Tseng [:ethan] from comment #6)
> This bug seems hard to reproduce. The only clue is it crashed at
> "ARTPConnection.cpp : 313".
> I'll look at codes around here to see if anything is suspicious.
> 
> Meanwhile, Pooja, could you provide more input?
> What HTTP and RTSP links did you use?
> Were you connecting to public servers or local servers set up on your own?
> Could you describe the step in more detail? Such as, what you mean "one
> after another"?
> Did you press back and click another link? Or you press the URL bar and
> click a history link?

Ethan, we are using the same app as mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1056187#c12 which takes an option to play either a http/rtsp stream we alternate the streams while stress testing.

Pooja please add any details that you have further.
(In reply to Ethan Tseng [:ethan] from comment #6)

> What HTTP and RTSP links did you use?

Its local links . If its really necessary can share over mail

> Were you connecting to public servers or local servers set up on your own?

Its a local server. We setup for testing

> Could you describe the step in more detail? Such as, what you mean "one
> after another"?
> Did you press back and click another link? Or you press the URL bar and
> click a history link?

As Bhargav mentioned in comment#7 its a small test app.

We automate it using few line script which stop/pause the playback if not completed and then again starts play by changing  video_tag.src to new url
Flags: needinfo?(poojas)
(In reply to Ethan Tseng [:ethan] from comment #6)
> This bug seems hard to reproduce. The only clue is it crashed at
> "ARTPConnection.cpp : 313".
> I'll look at codes around here to see if anything is suspicious.

Did we find something based on your investigation?
> 
> Meanwhile, Pooja, could you provide more input?
> What HTTP and RTSP links did you use?
> Were you connecting to public servers or local servers set up on your own?
> Could you describe the step in more detail? Such as, what you mean "one
> after another"?
> Did you press back and click another link? Or you press the URL bar and
> click a history link?

:ethan, can you confirm you have enough info in moving further here given comment #7/8 ?
Flags: needinfo?(ettseng)
(In reply to bhavana bajaj [:bajaj] from comment #9)
> Did we find something based on your investigation?
Not yet.
> :ethan, can you confirm you have enough info in moving further here given
> comment #7/8 ?
According to current information (crashed code stack) we presume the issue is about file descriptors.
One guess is that somewhere in HTTP or RTSP streaming module closes a wrong fd which is using by others.
We will try to figure out the root cause by following this clue and reading codes.
However, it will take longer time.
Flags: needinfo?(ettseng)
We have a bunch of bugs where we close fds improperly (bug 1057220 and dependencies) so we might want to retest with those fixes.
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #11)
> We have a bunch of bugs where we close fds improperly (bug 1057220 and
> dependencies) so we might want to retest with those fixes.

Thanks for the information! It seems closing invalid fd
on certain configuration would cause the subsequent 
fd operation to crash and Sotaro provided patches to 
catch those invalid fd closing. So, since it's difficult
to reproduce on our side, what we can do at this point is:

1) Apply the patches in bug 1057220.
2) Try to reproduce this bug.

If we still see this bug then it is not caused by previous
improper fd close. Pooja, what do you think?

Thanks!
Flags: needinfo?(poojas)
Okay Chang. Will ask our internal test team to try same STR with  patches in bug 1057220.
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #11)
> We have a bunch of bugs where we close fds improperly (bug 1057220 and
> dependencies) so we might want to retest with those fixes.
This is a valuable information. Thanks, Kyle!
blocking-b2g: 2.0? → 2.0+
Hi Pooja, any update from your side? Thanks.
Flags: needinfo?(poojas)
No idea and new finding after reading code. Could anyone apply
this patch to logcat more information? Thanks!
Howie,

I apologize for delay. We faced some technical problem.

Will update the results by tomorrow
Attached file crash dump with adb logcat (obsolete) —
We again received same crash  on latest build( has fixes as per bug 1057220 )

Please find the attached logs and crash dump.

Henry, We have started testing  with your debug patch too. Please let us know if you want to add other logs.
Flags: needinfo?(poojas)
Henry is working on this.
Assignee: nobody → hchang
(In reply to Pooja from comment #18)
> Created attachment 8484034 [details]
> crash dump with adb logcat
> 
> We again received same crash  on latest build( has fixes as per bug 1057220 )
> 
> Please find the attached logs and crash dump.
> 
> Henry, We have started testing  with your debug patch too. Please let us
> know if you want to add other logs.

Very happy to know this! By the way, the dropbox link points to 
an empty zip file.

Thanks!
Attached file crash dump (obsolete) —
Attachment #8484034 - Attachment is obsolete: true
Attached file crash logs and logcat (obsolete) —
Henry, Please confirm once if you are able to see logs.
Attachment #8484119 - Attachment is obsolete: true
(In reply to Pooja from comment #22)
> Created attachment 8484129 [details]
> crash logs and logcat
> 
> Henry, Please confirm once if you are able to see logs.

I am reading now! Thanks. However, I cannot grab any
information from the log. The log included no b2g process 
crash trace. (only has "pid: 14303, tid: 14303, name: trag  >>> trag <<<")
Do I interpret the log incorrectly?

Thanks
(In reply to Henry Chang [:henry] from comment #23)

> I am reading now! Thanks. However, I cannot grab any
> information from the log. The log included no b2g process 
> crash trace. (only has "pid: 14303, tid: 14303, name: trag  >>> trag <<<")
> Do I interpret the log incorrectly?
> 
> Thanks

Crash trace at 
https://www.dropbox.com/s/7lc4zqc7e09dgub/crash-dump.txt?dl=0
 is not sufficient enough. Logcat also looks proper to me. Please let me know if iam missing anything  here
Crash Signature: [@ PR_GetIdentitiesLayer | _pr_poll_with_poll | android::ARTPConnection::onPollStreams() | android::ALooperRoster::deliverMessage(android::spandroid::AMessage const&) ]
Ni, :henry (thanks !!) so this is on his radar to look at today given comment #24.
Flags: needinfo?(hchang)
I am still waiting for the latest log with my patch 
in comment 16 applied. I can do nothing without the 
log I desire to add.
Flags: needinfo?(hchang) → needinfo?(poojas)
Hi Henry,
Please look on logs collected with your patch.

Crash dump signature
-----
Thread 88 (crashed)
 0  libnss3.so!_pr_poll_with_poll [ptio.c : 3853 + 0x2]
     r0 = 0xa812af8c    r1 = 0x00000000    r2 = 0x00000000    r3 = 0x00000000
     r4 = 0x00000000    r5 = 0x00000000    r6 = 0xa9c4f640    r7 = 0x00000000
     r8 = 0x00000000    r9 = 0xa9c4f640   r10 = 0xa61aaaa8   r12 = 0x00000004
     fp = 0xffffffff    sp = 0xa61aaa80    lr = 0xb664b907    pc = 0xb664b916
    Found by: given as instruction pointer in context
 1  libxul.so!android::ARTPConnection::onPollStreams() [ARTPConnection.cpp : 327 + 0x11]
     r4 = 0x00000004    r5 = 0xa9c4f640    r6 = 0xa9c4f640    r7 = 0x00000004
     r8 = 0xab2ed820    r9 = 0xb5dc9510   r10 = 0xb5dc9b65    fp = 0xb6fc52ec
     sp = 0xa61aacd0    pc = 0xb4c2cfed
    Found by: call frame info
 2  libstagefright_foundation.so!android::ALooperRoster::deliverMessage(android::sp<android::AMessage> const&) [ALooperRoster.cpp : 148 + 0x7]
     r4 = 0xa61aad60    r5 = 0xab2ed820    r6 = 0x00000004    r7 = 0xb43bb024
     r8 = 0xb6ed3559    r9 = 0xa60ad000   r10 = 0xbe9f814c    fp = 0xb6fc52ec
     sp = 0xa61aad20    pc = 0xb43b3437
    Found by: call frame info
 3  libstagefright_foundation.so!android::ALooper::loop() [ALooper.cpp : 213 + 0x5]
     r4 = 0x00000001    r5 = 0xa61aad60    r6 = 0xab2ed7f0    r7 = 0xaa32480c
     r8 = 0xb6ed3559    r9 = 0xa60ad000   r10 = 0xbe9f814c    fp = 0xb6fc52ec
     sp = 0xa61aad48    pc = 0xb43b2f13
    Found by: call frame info
-------
Attachment #8484129 - Attachment is obsolete: true
Flags: needinfo?(poojas) → needinfo?(hchang)
The latest crash has slightly different crash point from the original one
Will you still be running the automation test with my patch so that I 
check if there are more than one cause of the crash?

By the way, from the latest log, there was an incomplete addStream/removeStream
pair. If I can have more crash logs that would help me identify if it's the
root cause.

Thanks.

(In reply to Pooja from comment #27)
> Created attachment 8486236 [details]
> crash dump and logcat with ARTPConnection debug logs
> 
> Hi Henry,
> Please look on logs collected with your patch.
> 
> Crash dump signature
> -----
> Thread 88 (crashed)
>  0  libnss3.so!_pr_poll_with_poll [ptio.c : 3853 + 0x2]
>      r0 = 0xa812af8c    r1 = 0x00000000    r2 = 0x00000000    r3 = 0x00000000
>      r4 = 0x00000000    r5 = 0x00000000    r6 = 0xa9c4f640    r7 = 0x00000000
>      r8 = 0x00000000    r9 = 0xa9c4f640   r10 = 0xa61aaaa8   r12 = 0x00000004
>      fp = 0xffffffff    sp = 0xa61aaa80    lr = 0xb664b907    pc = 0xb664b916
>     Found by: given as instruction pointer in context
>  1  libxul.so!android::ARTPConnection::onPollStreams() [ARTPConnection.cpp :
> 327 + 0x11]
>      r4 = 0x00000004    r5 = 0xa9c4f640    r6 = 0xa9c4f640    r7 = 0x00000004
>      r8 = 0xab2ed820    r9 = 0xb5dc9510   r10 = 0xb5dc9b65    fp = 0xb6fc52ec
>      sp = 0xa61aacd0    pc = 0xb4c2cfed
>     Found by: call frame info
>  2 
> libstagefright_foundation.so!android::ALooperRoster::deliverMessage(android::
> sp<android::AMessage> const&) [ALooperRoster.cpp : 148 + 0x7]
>      r4 = 0xa61aad60    r5 = 0xab2ed820    r6 = 0x00000004    r7 = 0xb43bb024
>      r8 = 0xb6ed3559    r9 = 0xa60ad000   r10 = 0xbe9f814c    fp = 0xb6fc52ec
>      sp = 0xa61aad20    pc = 0xb43b3437
>     Found by: call frame info
>  3  libstagefright_foundation.so!android::ALooper::loop() [ALooper.cpp : 213
> + 0x5]
>      r4 = 0x00000001    r5 = 0xa61aad60    r6 = 0xab2ed7f0    r7 = 0xaa32480c
>      r8 = 0xb6ed3559    r9 = 0xa60ad000   r10 = 0xbe9f814c    fp = 0xb6fc52ec
>      sp = 0xa61aad48    pc = 0xb43b2f13
>     Found by: call frame info
> -------
Flags: needinfo?(hchang)
Another potential bug which may cause crashes:

Whenever a RTSPConnectionHandler is going to abort, 2 main tasks will be done

1) Notify the RTPConnection to remove the streams. [1]
2) Close the sockets maintained in the track info. [2][3]

However, [1] is not a synchronous operation. Chances are RTPConnection
will be handling a scheduled polling task [4] where the sockets has 
been closed [2][3].

Pooja,

I am at home so that I cannot make a patch to add logs based on my
argument above. Are you able to help add adb log to [1][2][3]
on top of my previous patch to print out all activities regarding
all sockets? That could save one day turn around time! Thanks!




[1] http://hg.mozilla.org/releases/mozilla-b2g32_v2_0/file/de70f9a40834/netwerk/protocol/rtsp/rtsp/RTSPConnectionHandler.h#l855
[2] http://hg.mozilla.org/releases/mozilla-b2g32_v2_0/file/de70f9a40834/netwerk/protocol/rtsp/rtsp/RTSPConnectionHandler.h#l858
[3] http://hg.mozilla.org/releases/mozilla-b2g32_v2_0/file/de70f9a40834/netwerk/protocol/rtsp/rtsp/RTSPConnectionHandler.h#l862
[4] http://hg.mozilla.org/releases/mozilla-b2g32_v2_0/file/de70f9a40834/netwerk/protocol/rtsp/rtsp/ARTPConnection.cpp#l312
Flags: needinfo?(poojas)
Whiteboard: [caf-crash 325][caf priority: p1][b2g-crash][CR 712723] → [caf-crash 325][caf priority: p2][b2g-crash][CR 712723]
(In reply to Henry Chang [:henry] from comment #29)
 
> Pooja,
> 
> I am at home so that I cannot make a patch to add logs based on my
> argument above. Are you able to help add adb log to [1][2][3]

Hi Henry,
I have provided build to testers with  logs at [1][2][3].
Please look on below diff and let me know if you need any changes on same.

index f97fd08..3f98f3a 100644
--- a/netwerk/protocol/rtsp/rtsp/RTSPConnectionHandler.h
+++ b/netwerk/protocol/rtsp/rtsp/RTSPConnectionHandler.h
@@ -40,6 +40,10 @@
 #include "prio.h"
 #include "prnetdb.h"
 
+#include <android/log.h>
+
+#define ALOG(args...)   __android_log_print(ANDROID_LOG_WARN,  "RTPSConnectionHandler", ## args)
+
 extern PRLogModuleInfo* gRtspLog;
 
 // If no access units are received within 2 secs, assume that the rtp
@@ -852,13 +856,16 @@ struct RtspConnectionHandler : public AHandler {
                     }
 
                     if (!info->mUsingInterleavedTCP) {
+                        ALOG("calling  mRTPConn->removeStream with info->mRTPSocket : %p and info->mRTCPSocket : %p", info->mRTPSocket, info->mRTCPSocket);
                         mRTPConn->removeStream(info->mRTPSocket, info->mRTCPSocket);
 
                         if (info->mRTPSocket) {
+                            ALOG("Closing rtp-socket : %p", info->mRTPSocket);
                             PR_Close(info->mRTPSocket);
                         }
 
                         if (info->mRTCPSocket) {
+                             ALOG("Closing rtcp-socket : %p", info->mRTCPSocket);
                             PR_Close(info->mRTCPSocket);
                         }
                     }
Flags: needinfo?(poojas)
Attached patch ThisIsThePatch! (obsolete) — Splinter Review
I can reproduce the same crash stack by quickly refreshing rtsp streaming
so that I am almost-certain sure polling the closed sockets is the root
cause of this issue. Just attached a patch to using postAndAwaitResponse
to avoid polling closed sockets and it works perfectly for me. May it
also work for you :)
Pooja,

Thanks for your great help. I've also created a patch to address
the potential issue and I pretty much believe its the actual cause.

Thanks!

(In reply to Pooja from comment #30)
> (In reply to Henry Chang [:henry] from comment #29)
>  
> > Pooja,
> > 
> > I am at home so that I cannot make a patch to add logs based on my
> > argument above. Are you able to help add adb log to [1][2][3]
> 
> Hi Henry,
> I have provided build to testers with  logs at [1][2][3].
> Please look on below diff and let me know if you need any changes on same.
> 
> index f97fd08..3f98f3a 100644
> --- a/netwerk/protocol/rtsp/rtsp/RTSPConnectionHandler.h
> +++ b/netwerk/protocol/rtsp/rtsp/RTSPConnectionHandler.h
> @@ -40,6 +40,10 @@
>  #include "prio.h"
>  #include "prnetdb.h"
>  
> +#include <android/log.h>
> +
> +#define ALOG(args...)   __android_log_print(ANDROID_LOG_WARN, 
> "RTPSConnectionHandler", ## args)
> +
>  extern PRLogModuleInfo* gRtspLog;
>  
>  // If no access units are received within 2 secs, assume that the rtp
> @@ -852,13 +856,16 @@ struct RtspConnectionHandler : public AHandler {
>                      }
>  
>                      if (!info->mUsingInterleavedTCP) {
> +                        ALOG("calling  mRTPConn->removeStream with
> info->mRTPSocket : %p and info->mRTCPSocket : %p", info->mRTPSocket,
> info->mRTCPSocket);
>                          mRTPConn->removeStream(info->mRTPSocket,
> info->mRTCPSocket);
>  
>                          if (info->mRTPSocket) {
> +                            ALOG("Closing rtp-socket : %p",
> info->mRTPSocket);
>                              PR_Close(info->mRTPSocket);
>                          }
>  
>                          if (info->mRTCPSocket) {
> +                             ALOG("Closing rtcp-socket : %p",
> info->mRTCPSocket);
>                              PR_Close(info->mRTCPSocket);
>                          }
>                      }
Attachment #8487028 - Flags: review?(sworkman)
(In reply to Henry Chang [:henry] from comment #32)
> I can reproduce the same crash stack by quickly refreshing rtsp streaming
> so that I am almost-certain sure polling the closed sockets is the root
> cause of this issue. Just attached a patch to using postAndAwaitResponse
> to avoid polling closed sockets and it works perfectly for me. May it
> also work for you :)

Thanks, Henry!
Good catch!
HI Henry,
Thanks for your fix :)
I have given the build with your fix to tester. Lets wait for their update.
Fix looks reasonable to me, but I want to wait for feedback from the testers.
Thanks Henry for the fix. 

It passed for 300 iteration without crash and still its running. Earlier  crash was observed  in initiall runs (10-20).
Hopefully the fix worked. But lets wait for the testers to come up with final test results
Comment on attachment 8487028 [details] [diff] [review]
ThisIsThePatch!

Review of attachment 8487028 [details] [diff] [review]:
-----------------------------------------------------------------

300 tests is good enough progress for me. Seems like you should wait for final confirmation from Pooja's comment. In the meantime, r=me.

::: netwerk/protocol/rtsp/rtsp/ARTPConnection.cpp
@@ +182,5 @@
>          case kWhatRemoveStream:
>          {
>              onRemoveStream(msg);
> +            // Reply a dummy response.
> +            sp<AMessage> response = new AMessage;

nit: I think you can remove this comment and s/response/ack/.
Attachment #8487028 - Flags: review?(sworkman) → review+
Hi Pooja, any update on the final test results? Thanks.
Flags: needinfo?(poojas)
(In reply to howie [:howie] from comment #39)
> Hi Pooja, any update on the final test results? Thanks.

Sorry, could not update it early.

Issue is been fixed. We are not seeing any crash again.

Thanks everybody for working on this. :)
Flags: needinfo?(poojas)
Comment on attachment 8487028 [details] [diff] [review]
ThisIsThePatch!

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): RTSP
[User impact] if declined: Quickly reloading RTSP streaming will cause b2g crash
[Testing completed]: Yes
[Risk to taking this patch] (and alternatives if risky): No
[String changes made]: No
Attachment #8487028 - Flags: approval-gaia-v2.0?
Comment on attachment 8487028 [details] [diff] [review]
ThisIsThePatch!

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): RTSP
[User impact] if declined: Quickly reloading RTPS will cause b2g crash
[Testing completed]: Yest
[Risk to taking this patch] (and alternatives if risky): No
[String changes made]: No
Attachment #8487028 - Flags: approval-gaia-v2.1?
Comment on attachment 8487028 [details] [diff] [review]
ThisIsThePatch!

Cancel 2.1+ approval since it has no explicit branch yet.
Attachment #8487028 - Flags: approval-gaia-v2.1?
Attachment #8487028 - Flags: approval-gaia-v2.0? → approval-gaia-v2.0+
Comment on attachment 8487028 [details] [diff] [review]
ThisIsThePatch!

Switching back to ? as this needs to land on master first.
Attachment #8487028 - Flags: approval-gaia-v2.0+ → approval-gaia-v2.0?
Hi Henry, please help to land this on master first. After it's fixed, request approval flag: approval‑mozilla‑b2g32 (v2.0). If the patch also apply to v2.1, please request the following approval too: approval‑mozilla‑aurora.
Flags: needinfo?(hchang)
Addressing the review comments.
Attachment #8487028 - Attachment is obsolete: true
Attachment #8487028 - Flags: approval-gaia-v2.0?
Comment on attachment 8489836 [details] [diff] [review]
Updated patch v1.1 r=sworkman

Approval Request Comment
[Feature/regressing bug #]: RTSP
[User impact if declined]: Quickly reloading RTPS will cause b2g crash
[Describe test coverage new/current, TBPL]: Testing completed manually
[Risks and why]: No
[String/UUID change made/needed]: No
Attachment #8489836 - Flags: approval-mozilla-b2g32?
Attachment #8489836 - Flags: approval-mozilla-aurora?
waiting on central landing before getting to branch approval.
Flags: needinfo?(hchang)
https://hg.mozilla.org/mozilla-central/rev/8dc686845d16
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S5 (26sep)
[Blocking Requested - why for this release]:
blocking-b2g: 2.0+ → 2.1?
Can we please merge it for 2.1 also
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Flags: needinfo?(vchang)
(In reply to Pooja from comment #51)
> [Blocking Requested - why for this release]:

Pooja, can you please NI me before switching the blocking flag if there is a concern on landing on a particular branch. IN this particular case the blocking flags would be set as 2.0+ as that is the highest release branch that is impacted. Any subsequent versions of b2G will get the patches by just an approval request.

(In reply to Pooja from comment #52)
> Can we please merge it for 2.1 also

The aurora approval here is indicative of this landing on 2.1. The gecko(34) for 2.1 s currently riding the aurora train. Also, a bug is marked "RESOLVED FIXED" once it lands on mozilla-central. You'd have to rely on status flags status-b2g-v2.0,status-b2g-v2.1 to get the branch status, hence I am marking this bug as resolved fixed.
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Attachment #8489836 - Flags: approval-mozilla-b2g32?
Attachment #8489836 - Flags: approval-mozilla-b2g32+
Attachment #8489836 - Flags: approval-mozilla-aurora?
Attachment #8489836 - Flags: approval-mozilla-aurora+
Observed on: 

Device: msm8226
Gonk Version: AU_LINUX_GECKO_B2G_KK_2.0.01.04.00.114.084
Moz BuildID: 20140916000206
B2G Version: 2.0
Gecko Version: 34.0a2
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=713448b8963cd53c561f4b38640f8c63b655ce33
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=395370094caa386ebf8fe8831d030bc5484fa599
Patches: bug 1055299, bug 1044125, bug 1051633, bug 1063877, bug 1064376, bug 1057220
Flags: needinfo?(vchang)
You need to log in before you can comment on or make changes to this bug.