1318943 - Crash when parsing "chrome:" as a URI (Crash in xul.dll@0x5eff6 | xul.dll@0x61eea | mozilla::net::RustURL::GetFilePath)

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Giorgio Maone [:ma1]]

This bug was filed from the Socorro interface and is 
report bp-c880e122-6474-431e-aef3-e688d2161120.
=============================================================

Comment 1

[Giorgio Maone [:ma1]]

Sorry, crashing the parent process notwithstanding e10s turns out to be really simple.
Just issue a HTTP redirect to "chrome:", like (in PHP)

<?php
header('Location: chrome:')

See (warning: you'll crash the whole browser immediately)
https://maone.net/test/bugs/chrome-scheme-crash/

Comment 2

[Josh Matthews [:jdm]]

[Tracking Requested - why for this release]: Parent process crash.

Comment 3

[Manish Goregaokar [:manishearth]]

rust-url bug filed at https://github.com/servo/rust-url/issues/241

Comment 4

[Manish Goregaokar [:manishearth]]

Can confirm that this gets fixed by https://github.com/servo/rust-url/pull/242

However, bug 1318432 is the correct fix to land for this crash. Once my rust-url PR merges we can update the rust-url version to pull this in, but we should avoid shipping rust-url in nightly enabled by default for now anyway.

Comment 6

[Nicholas Nethercote [inactive]]

Ted, this is a crash signature with some xul.dll@0xBLAH entries. Does that indicate missing symbols? Is it a weird Rust-only thing? Seems like something you might be interested in...

Comment 7

[Nicholas Nethercote [inactive]]

(In reply to Nicholas Nethercote [:njn] from comment #6)
> Ted, this is a crash signature with some xul.dll@0xBLAH entries. Does that
> indicate missing symbols? Is it a weird Rust-only thing? Seems like
> something you might be interested in...

See also bug 1319298, which is about improving the crash signature for these crashes on Mac and Linux.

Comment 8

[(not currently active) Ted Mielczarek]

It's definitely not missing symbols in the way we usually talk about them (there are very clearly symbols for xul.dll in the frames below), but something is not right there. Given that this is a crash in Rust code it seems pretty likely that something is going wrong with symbol dumping for the Rust functions.

Comment 9

[(not currently active) Ted Mielczarek]

Interestingly frame 2 is clearly calling rusturl_get_path (from the crash report in comment 0):
https://hg.mozilla.org/mozilla-central/annotate/57a8cde3f08c/netwerk/base/RustURL.cpp#l477

and the symbol file for libxul has an entry for that function (I downloaded it from the link on the Modules tab):
FUNC 3a7a0 88 0 rust_url_capi::rusturl_get_path

...but it's at a different offset. I'll grab the PDB file and run it through dump_syms locally to see if I can figure out what's going on here.

Comment 10

[Marcia Knous [:marcia]]

Carrying over tracking flag from the duplicate.

Comment 11

[(not currently active) Ted Mielczarek]

I updated to the latest nightly, flipped on the network.standard-url.enable-rust pref, and clicked the test URL and was able to produce this crash:
https://crash-stats.mozilla.com/report/index/95603eb6-4f4d-49a1-9752-3ff1c2161129

I had theorized (on IRC, apparently) that the top frames without symbols were because we didn't have symbols for libstd. Since bug 1318531 landed we now have symbols for those frames.

Comment 12

[Nicholas Nethercote [inactive]]

> I had theorized (on IRC, apparently) that the top frames without symbols
> were because we didn't have symbols for libstd. Since bug 1318531 landed we
> now have symbols for those frames.

Excellent. The signature for that crash is [@ std::panicking::rust_panic_with_hook]. Once https://github.com/mozilla/socorro/pull/3601 lands (just waiting for the Socorro freeze to end, should be any day now) any such future crashes will get a better signature due to better handling of the Rust panic frames via the skiplists.

Comment 13

[Marcia Knous [:marcia]]

(In reply to Nicholas Nethercote [:njn] from comment #12)
> > I had theorized (on IRC, apparently) that the top frames without symbols
> > were because we didn't have symbols for libstd. Since bug 1318531 landed we
> > now have symbols for those frames.
> 
> Excellent. The signature for that crash is [@
> std::panicking::rust_panic_with_hook]. Once
> https://github.com/mozilla/socorro/pull/3601 lands (just waiting for the
> Socorro freeze to end, should be any day now) any such future crashes will
> get a better signature due to better handling of the Rust panic frames via
> the skiplists.

So it looks like that pull landed - so do we just need to reprocess the signatures?

Comment 14

[Marcia Knous [:marcia]]

I got a slightly different crash signature when I reproduced on Windows - [@ rust_url_capi::rusturl_get_path ].

Should we close out this bug if it fixed by the pull in Comment 4?

Comment 15

[(not currently active) Ted Mielczarek]

Manish: did you update the in-tree rust-url to fix this? If so we can mark this FIXED.

Comment 16

[(not currently active) Ted Mielczarek]

(In reply to Marcia Knous [:marcia - use ni] from comment #14)
> I got a slightly different crash signature when I reproduced on Windows - [@
> rust_url_capi::rusturl_get_path ].

Thanks for checking, that's expected as the result of bug 1318531 + bug 1319298.

Comment 18

[David Bolter [:davidb] (NeedInfo me for attention)]

Hi Valentin, we looked at this during regression triage today. Any traction on this issue?

Comment 19

[Valentin Gosu [:valentin] (he/him)]

Should be fixed now that we updated rust-url in bug 1339809.