1058022 - B2G crashes during RTSP and HTTP streaming playback

Status: RESOLVED FIXED

(Firefox OS Graveyard :: RTSP, defect)

Description

[Pooja]

Attachment: 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"

Comment 1

[Pooja]

[Blocking Requested - why for this release]:

Comment 2

[cafbot (PoC: ggrisco)]

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

Comment 3

[bhavana bajaj [:bajaj]]

Waiting for more information from CAF on them testing this with latest gecko/gaia cset before blocking here.

Comment 4

[bhargavg1]

(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?

Comment 5

[Ken Chang[:kenkai]]

Ethen, can we get any clue form description?

Comment 6

[Ethan Tseng [:ethan]]

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?

Comment 7

[bhargavg1]

(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.

Comment 8

[Pooja]

(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

Comment 9

[bhavana bajaj [:bajaj]]

(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 ?

Comment 10

[Ethan Tseng [:ethan]]

(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.

Comment 11

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

We have a bunch of bugs where we close fds improperly (bug 1057220 and dependencies) so we might want to retest with those fixes.

Comment 12

[Henry Chang [:hchang]]

(In reply to Kyle Huey [:khuey] ([e-mail]) 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!

Comment 13

[Pooja]

Okay Chang. Will ask our internal test team to try same STR with  patches in bug 1057220.

Comment 14

[Ethan Tseng [:ethan]]

(In reply to Kyle Huey [:khuey] ([e-mail]) 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!

Comment 15

[howie [:howie]]

Hi Pooja, any update from your side? Thanks.

Comment 16

[Henry Chang [:hchang]]

Attachment: AddLogForDebugging.patch

No idea and new finding after reading code. Could anyone apply
this patch to logcat more information? Thanks!

Comment 17

[Pooja]

Howie,

I apologize for delay. We faced some technical problem.

Will update the results by tomorrow

Comment 18

[Pooja]

Attachment: 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.

Comment 19

[Vincent Chang[:vchang][changyihsin]]

Henry is working on this.

Comment 20

[Henry Chang [: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!

Comment 21

[Pooja]

Attachment: crash dump

Comment 22

[Pooja]

Attachment: crash logs and logcat

Henry, Please confirm once if you are able to see logs.

Comment 23

[Henry Chang [:hchang]]

(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

Comment 24

[Pooja]

(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

Comment 25

[bhavana bajaj [:bajaj]]

Ni, :henry (thanks !!) so this is on his radar to look at today given comment #24.

Comment 26

[Henry Chang [: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.

Comment 27

[Pooja]

Attachment: 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
-------

Comment 28

[Henry Chang [: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
> -------

Comment 29

[Henry Chang [: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

Comment 30

[Pooja]

(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);
                         }
                     }

Comment 31

[Henry Chang [:hchang]]

Attachment: ThisIsThePatch!

Comment 32

[Henry Chang [:hchang]]

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 :)

Comment 33

[Henry Chang [:hchang]]

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);
>                          }
>                      }

Comment 34

[Ethan Tseng [:ethan]]

(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!

Comment 35

[Pooja]

HI Henry,
Thanks for your fix :)
I have given the build with your fix to tester. Lets wait for their update.

Comment 36

[Steve Workman [:sworkman] (INACTIVE)]

Fix looks reasonable to me, but I want to wait for feedback from the testers.

Comment 37

[Pooja]

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 38

[Steve Workman [:sworkman] (INACTIVE)]

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/.

Comment 39

[howie [:howie]]

Hi Pooja, any update on the final test results? Thanks.

Comment 40

[Pooja]

(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. :)

Comment 41

[Henry Chang [:hchang]]

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

Comment 42

[Henry Chang [:hchang]]

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

Comment 43

[Henry Chang [:hchang]]

Comment on attachment 8487028 [details] [diff] [review]
ThisIsThePatch!

Cancel 2.1+ approval since it has no explicit branch yet.

Comment 44

[bhavana bajaj [:bajaj]]

Comment on attachment 8487028 [details] [diff] [review]
ThisIsThePatch!

Switching back to ? as this needs to land on master first.

Comment 45

[howie [:howie]]

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.

Comment 46

[Vincent Chang[:vchang][changyihsin]]

Attachment: Updated patch v1.1 r=sworkman

Addressing the review comments.

Comment 47

[Vincent Chang[:vchang][changyihsin]]

https://hg.mozilla.org/integration/b2g-inbound/rev/8dc686845d16

Comment 48

[Vincent Chang[:vchang][changyihsin]]

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

Comment 49

[bhavana bajaj [:bajaj]]

waiting on central landing before getting to branch approval.

Comment 50

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/8dc686845d16

Comment 51

[Pooja]

[Blocking Requested - why for this release]:

Comment 52

[Pooja]

Can we please merge it for 2.1 also

Comment 53

[bhavana bajaj [:bajaj]]

(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.

Comment 54

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/afafa9e04231
https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/1dffeb64add5

Comment 55

[cafbot (PoC: ggrisco)]

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

Comment 56

[Kai-Zhen Li [:seinlin][:kli]]

http://hg.mozilla.org/releases/mozilla-b2g32_v2_0m/rev/1dffeb64add5