865915 - Sending save profile signal causes a crash

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[William Lachance (:wlach)]

Since the nightlies from the 23rd or 24th saving a SPS profile has caused fennec to crash (saving the profile seems to succeed, the crash comes right after).

I will attach a logcat and a crashdump for more info.

Comment 1

[William Lachance (:wlach)]

Attachment: Logcat of crash

Comment 2

[William Lachance (:wlach)]

Attachment: crashdump

Comment 3

[William Lachance (:wlach)]

Ok, determined that this doesn't happen in the nightly of the 23rd, but does in the 24th. That pins it down to:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=acf388eaf9e9&tochange=fef5f202b2dc

Comment 4

[Scoobidiver (away)]

Are bp-9a9ff32a-2d23-46a7-b686-f08a02130425 and bp-53e57855-b84a-4f2b-be43-f012b2130425 your crash reports from about:crashes?

Comment 5

[William Lachance (:wlach)]

(In reply to Scoobidiver from comment #4)
> Are bp-9a9ff32a-2d23-46a7-b686-f08a02130425 and
> bp-53e57855-b84a-4f2b-be43-f012b2130425 your crash reports from
> about:crashes?

Not sure, how do I determine this?

Comment 6

[William Lachance (:wlach)]

I'm pretty sure I've isolated this to bug 788022. Disabling some of the code causes this crash to no longer occur:

diff --git a/tools/profiler/TableTicker.cpp b/tools/profiler/TableTicker.cpp
index 7650773..24f1906 100644
--- a/tools/profiler/TableTicker.cpp
+++ b/tools/profiler/TableTicker.cpp
@@ -258,7 +258,7 @@ void TableTicker::BuildJSObject(JSAObjectBuilder& b, JSCusto
     }
   }
 
-#if defined(SPS_OS_android) && !defined(MOZ_WIDGET_GONK)
+#if 0 && defined(SPS_OS_android) && !defined(MOZ_WIDGET_GONK)
   if (ProfileJava()) {
     AndroidBridge::Bridge()->PauseJavaProfiling();
 
Not really sure why this is as :BenWa told me that java profiling is supposed to be disabled by default?

Comment 7

[Scoobidiver (away)]

(In reply to William Lachance (:wlach) from comment #5)
> Not sure, how do I determine this?
Type about:crashes in the location bar and post your crash IDs.

Comment 8

[Benoit Girard (:BenWa)]

(In reply to Scoobidiver from comment #4)
> Are bp-9a9ff32a-2d23-46a7-b686-f08a02130425 and
> bp-53e57855-b84a-4f2b-be43-f012b2130425 your crash reports from
> about:crashes?

My analysis shows me that it is infact this and not the java profiling bits.

This was introduced in bug 863766.

Comment 9

[Andrew McCreight [:mccr8]]

It seems bad to be deleting a JSContext with outstanding requests...

Comment 10

[Benoit Girard (:BenWa)]

Attachment: Fixed unmatched JS_EndRequest

Comment 11

[Andrew McCreight [:mccr8]]

Comment on attachment 743183 [details] [diff] [review]
Fixed unmatched JS_EndRequest

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

Weird that this didn't trigger an assertion in JS_EndRequest.

Comment 12

[Benoit Girard (:BenWa)]

(In reply to Andrew McCreight [:mccr8] from comment #11)
> Comment on attachment 743183 [details] [diff] [review]
> Fixed unmatched JS_EndRequest
> 
> Review of attachment 743183 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Weird that this didn't trigger an assertion in JS_EndRequest.

Profile code rarely runs under debug since it makes profile useless.

Comment 13

[Benoit Girard (:BenWa)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6a0948b0cd69

Comment 14

[Andrew McCreight [:mccr8]]

Ah, makes sense!

Comment 15

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/6a0948b0cd69