1437361 - firefox segfaults on first page load with umatrix extension

Status: RESOLVED DUPLICATE of bug 1430818

(Core :: DOM: Core & HTML, defect, P3)

Description

[Alexander Sergeyev]

Attachment: Stack trace for the crash (debug build)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20100101

Steps to reproduce:

Note: this specific problem is originally filed against umatrix extension (https://github.com/gorhill/uMatrix/issues/949). But since the firefox process crashes with a segmentation fault, it seems there might be unsufficient validation & sanity checks along the way. That is the primary concern for this bug filing.  

Steps to reproduce:
- install firefox 58.0.1
- make sure no prior profile data is present (move or delete ~/.mozilla)
- open the browser, navigate to about:config and set the following prefs:
    privacy.sanitize.sanitizeOnShutdown = true
    privacy.sanitize.timeSpan = 0
- navigate to about:addons; install umatrix extension (1.3.2)
- click preferences on umatrix addon and load the following ruleset:
    https-strict: behind-the-scene false
    matrix-off: about-scheme true
    matrix-off: behind-the-scene true
    matrix-off: chrome-extension-scheme true
    matrix-off: chrome-scheme true
    matrix-off: moz-extension-scheme true
    matrix-off: opera-scheme true
    matrix-off: wyciwyg-scheme true
    noscript-spoof: * true
    referrer-spoof: * true
    referrer-spoof: behind-the-scene false
    * * * block
    * * css allow
    * * frame block
    * * image allow
    * 1st-party * allow
    * 1st-party frame allow
    felixcloutier.com 1st-party * inherit
    www.felixcloutier.com 1st-party frame inherit
- commit the ruleset (via a button)
- navigate to http://www.felixcloutier.com/x86/CPUID.xml


Actual results:

"Gah. Your tab just crashed". This happens the first time the page is accessed, but then works fine (until restart).


Expected results:

An error message about unability to perform xslt transform (ie not a crash).

Comment 1

[roxleitan]

Managed to reproduce this issue on Firefox 58.0.2 and Nightly 60.0a1(2018-02-13) on Windows 10 x64 using the STR from the description.

The issue is not reproducible with the default values of preferences: "privacy.sanitize.sanitizeOnShutdown=False"  and "privacy.sanitize.timeSpan=1".

Comment 2

[Andrew Overholt [:overholt]]

Wennie, this feels like something your team would be interested in.
Roxana, since you can reproduce, is there a chance you can get a regression window?

Comment 3

[roxleitan]

Hi Andrew,

I cannot reproduce the issue anymore on Firefox 58.0.1 or latest Nightly 61.0a1 with umatrix, version 1.3.2 or 1.3.4 using the same STR. 

Please note that the latest umatrix version is 1.3.4.

Alexander, can you reproduce the issue using the latest umatrix version 1.3.4?

Comment 4

[Alexander Sergeyev]

Hi,

> can you reproduce the issue using the latest umatrix version 1.3.4?

I will look into that, though it might take some time (hopefully, within day window).

Regarding the latest version -- I'm not sure that is the goal: whatever is happening in the extension js code, the worker process should not crash. I mean the 1.3.4 version might be changed in a way so it no longer triggers the problem, but it would not mean that there is no problem anymore.

Comment 5

[Alexander Sergeyev]

> I will look into that, though it might take some time

I cannot reproduce the issue as well on 59.0.2 and umatrix 1.3.2/1.3.4.
I will try to recompile 58.0.1 in a clean vm sometime this week.

Comment 6

[Andrew Overholt [:overholt]]

(In reply to Alexander Sergeyev from comment #4)
> Regarding the latest version -- I'm not sure that is the goal: whatever is
> happening in the extension js code, the worker process should not crash. I
> mean the 1.3.4 version might be changed in a way so it no longer triggers
> the problem, but it would not mean that there is no problem anymore.

I think it's more to have a clear STR (steps to reproduce) so we can debug and fix :)

Comment 7

[Alexander Sergeyev]

Sorry it took that long, but I finally get my hands on the problem.

> I cannot reproduce the issue anymore on Firefox 58.0.1 or latest Nightly 61.0a1 with umatrix, version 1.3.2 or 1.3.4 using the same STR. 

Same here, but I have a good idea about the reason.

As can be seen in the original STR, the original page was actually xml (with xslt transformation into html). Now, the link is redirected to .html and there are no xslt transformations happening client-side. So, to continue with this problem we would require either an another similarly functioning page/testcase or some backup version of the original page.

Comment 8

[Alex Vincent [:WeirdAl]]

https://web.archive.org/web/*/https://github.com/gorhill/uMatrix/ maybe?

Comment 9

[Alexander Sergeyev]

(In reply to Alex Vincent [:WeirdAl] from comment #8)
> https://web.archive.org/web/*/https://github.com/gorhill/uMatrix/ maybe?

The problem is not about an unavailable umatrix build (it is available at https://addons.mozilla.org/en-US/firefox/addon/umatrix/versions/).
I meant that http://www.felixcloutier.com/x86/CPUID.xml is changed. When the bug was reported, the page performed XSLT transformation from an XML document, but now it's redirecting to html page.

Comment 10

[Wennie]

Hi Baku, please take a look at this. thanks!

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 12

[Andrea Marchesini [:baku]]

Alexander, Is it possible to have a copy of of that XML + XSLT?

peterv, do you have ideas about why we crash here? It seems that mSource is null when notifyError() is called. This can happen (if I read the code correctly) only if: CreateDocumentFragment() returns null.

Comment 13

[Alexander Sergeyev]

Attachment: Bundle with xml and xslt sources from archive.org

Comment 14

[Alexander Sergeyev]

Hi,

(In reply to Andrea Marchesini [:baku] from comment #12)

Alexander, Is it possible to have a copy of of that XML + XSLT?

I'm not affiliated with the site from STR, but was using it at the time. I didn't make a copy of fetched pages then, but it seems to be possible to use data from archive.org. Its use doesn't guarantee a successful bug reproduction, but maybe it's worth a try. I've attached an archive with such source files.

Comment 15

[Peter Van der Beken [:peterv]]

I'm going to mark this as a duplicate of bug 1430818, which I think fixed this.