Investigate high number of crash signatures that have javascript: urls

NEW
Unassigned

Status

()

Core
JavaScript Engine
7 years ago
3 years ago

People

(Reporter: marcia, Unassigned)

Tracking

6 Branch
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
Created attachment 554995 [details]
Sample report

Discussed in the CrashKill meeting. chofmann ran a report recently which showed a high number of crash signatures that have JS urls and thought we should probe further. I have attached the txt file for review by dmandelin.
(In reply to Marcia Knous [:marcia] from comment #0)
> Created attachment 554995 [details]
> Sample report
> 
> Discussed in the CrashKill meeting. chofmann ran a report recently which
> showed a high number of crash signatures that have JS urls and thought we
> should probe further. I have attached the txt file for review by dmandelin.

I don't know how to read this report format.

Comment 2

7 years ago
lines like "5.0.1 rank# 3"  

       show the ranking of the signature and any associated bug number with that signature.

the list of lines underneath each signature like:

      6 "javascript:"""""//
      5 javascript:window.parent.rmAdIframeSrc//
      6 "javascript:"""""
      5 javascript:window.parent.rmAdIframeSrc
      2 javascript:window.parent.abanIframeSrc

show the count of crash urls where "javascript:" urls show up in the crash reports for that signature.

The key thing we want to try and figure out here is if there is something interesting in the content of of a wide variety of pages that we could abstract as a test case, or if there is something in the chrome that puts javascript: urls in the history list and then we stumble along and crash right after that action.

do we know of any use patterns like this?

Comment 3

7 years ago
bclary might be able to help figure out if there are any interesting patterns on the content side of this question.

Also should add that all these javascript: urls might be innocent bystanders in the crashes, but they see so pervasive across a wide variety of signatures that we should just make sure they are not behind some pattern that produces a wide variety of signatures and reflective of a deeper problem.

Comment 4

7 years ago
crashes with some form of javascript: url dropped from ~1000 to ~800 (~10-20%) on 2011-06-23 when Firefox 5 and Firefox 6 Beta released with the fix for bug 656433 landed.

Looking at yesterday's stats I see the top "urls" as:

    447 "javascript:"""""
    231 javascript:false;
     53 javascript:''
     17 javascript:false

with a handful of crashes involving javascript:raw dom related code like the window.parent stuff in comment 2 and a handful from google ads where the pattern is "javascript:""html markup with iframe"

Looking at the occurrences by branch for yesterday's stats, I see this is primarily Windows (with a handful of Mac OS X) scattered across all branches: 3.6.x, 4.x, 5.x, 6.x, 7.x, 8.x, 9.x.

The quoted "javascript:""""" stuff definitely seems weird. I'm rebuilding stuff atm, but I'll try to reproduce on my windows vm when they finish.

Comment 5

7 years ago
Created attachment 555064 [details]
stack ASSERTION: Uh, cx is not the current JS context!: 'cx == GetCurrentJSContext()', file c:/work/mozilla/builds/nightly/mozilla/caps/src/nsScriptSecurityManager.cpp, line 396

1. start debug Nightly on WinXP
2. Attach debugger
3. Open Web developer console
4. document.location.href = 'javascript:false'

ASSERTION: Uh, cx is not the current JS context!: 'cx == GetCurrentJSContext()', file c:/work/mozilla/builds/nightly/mozilla/caps/src/nsScriptSecurityManager.cpp, line 396

A funny thing happens if you do 

document.location.href = '<html><body></body></html>' (or other markup)

It tries to load

jar:file:///C:/cygwin/home/bclary/bin/nightly/firefox/omni.jar!/chrome/browser/content/browser/%3Chtml%3E%3Cbody%3E%3C/body%3E%3C/html%3E

I was able to crash once in a debug build, but only after I disconnected the debugger so I didn't get the stack.
(Assignee)

Updated

4 years ago
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.