Closed Bug 865915 Opened 10 years ago Closed 10 years ago

Sending save profile signal causes a crash

Categories

(Firefox for Android Graveyard :: General, defect)

x86_64
Linux
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 23

People

(Reporter: wlach, Assigned: BenWa)

References

Details

(Keywords: crash, Whiteboard: [native-crash])

Attachments

(3 files)

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.
Attached file Logcat of crash
Attached file crashdump
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
Attachment #742087 - Attachment mime type: text/x-vhdl → text/plain
Severity: normal → critical
Keywords: crash
Whiteboard: [native-crash]
Are bp-9a9ff32a-2d23-46a7-b686-f08a02130425 and bp-53e57855-b84a-4f2b-be43-f012b2130425 your crash reports from about:crashes?
Flags: needinfo?(wlachance)
(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?
Flags: needinfo?(wlachance)
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?
Blocks: 788022
(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.
(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.
Blocks: 863766
It seems bad to be deleting a JSContext with outstanding requests...
Assignee: nobody → bgirard
Status: NEW → ASSIGNED
Attachment #743183 - Flags: review?(continuation)
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.
Attachment #743183 - Flags: review?(continuation) → review+
(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.
Ah, makes sense!
https://hg.mozilla.org/mozilla-central/rev/6a0948b0cd69
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 23
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.