832796 - Crash in mozalloc_abort | NS_DebugBreak_P | mozilla::net::PNeckoChild::Write when viewing articles on wired.com

Status: VERIFIED WORKSFORME

(Core :: Networking, defect)

Description

[Tarek Ziadé (:tarek)]

I was able to reproduce this on my phone (I am on the current up-to-date beta)

I just hope this can be reproduced by others, even if that website changes. Let me know if there are things I can do to narrow it down


1/ open firefox
2/ visit http://wired.com
3/ scroll down - when you reach the 4th big image, the OS crashes and restarts...

Comment 1

[Scoobidiver (away)]

Can you provide the crash ID? I think it's in the about:crashes page of the browser.

Comment 2

[Tarek Ziadé (:tarek)]

That page does not load anything. The page seem empty.

I crashed it again right now - I clicked on the "report" button on the "firefox os just crashed" message. Is there a way to get that report id in another place ?

Comment 3

[Tarek Ziadé (:tarek)]

I have my IP if this helps digging it in socorro ?

Comment 4

[Scoobidiver (away)]

(In reply to Tarek Ziadé (:tarek) from comment #2)
> Is there a way to get that report id in another place ?
Settings > Improve Firefox OS > Crash Data.

(In reply to Tarek Ziadé (:tarek) from comment #3)
> I have my IP if this helps digging it in socorro ?
IP addresses are not collected for privacy issues.

Comment 5

[Tarek Ziadé (:tarek)]

I don't have a "Crash Data" there. Just a "Crash report" where I can configure if the reports are sent.

I am on Boot2Gecko 1.0.0-prerelease. I mounted the media storage but did not find those there

Comment 6

[Scoobidiver (away)]

Can you provide a logcat then (see http://shizen008.wordpress.com/2012/09/13/logcatting-on-b2g/)?

Comment 7

[David Scravaglieri [:scravag]]

Chris, Justin, according to Dale, this could be a platform issue. Could you investigate ?

Comment 8

[Tarek Ziadé (:tarek)]

Sorry I had not the time yet to build the logcat - will do that tomorrow. 

Notice that this is not happening anymore on wired.com since they changed their homepage.

Comment 9

[Justin Lebar (not reading bugmail)]

Renoming because I do not think we can block on an issue which we cannot reproduce.

Comment 10

[Ben Francis [:benfrancis]]

Thanks Justin, I was just going to say the same thing. I've not been able to reproduce this and we're unable to act on it without reliable STR.

Marked QA wanted in case they can reproduce but it's likely more information is needed.

Comment 11

[Jason Smith [:jsmith]]

Attachment: Logcat - Abnormal Tab Termination, No Crash in Browser

I didn't get a OS restart crash, but I definitely got a tab crash eventually after playing around with some of the wired.com articles.

Comment 12

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #11)
> Created attachment 705229 [details]
> Logcat
> 
> I didn't get a OS restart crash, but I definitely got a tab crash eventually
> after playing around with some of the wired.com articles.

I should note that I mean to say that the tab abnormally stopped loading content. No crash report on this one though as a result.

Comment 13

[Jason Smith [:jsmith]]

Well this doesn't look friendly:

01-22 20:32:15.636: I/Gecko(107): NeckoParent::AllocPHttpChannel: FATAL error: missing required PBrowser argument: KILLING CHILD PROCESS
01-22 20:32:15.636: I/Gecko(107): ###!!! [Parent][AsyncChannel] Error: Value error: message was deserialized, but contained an illegal value
01-22 20:32:15.636: I/Gecko(107): ###!!! [Parent][AsyncChannel] Error: Route error: message sent to unknown actor ID
01-22 20:32:15.646: I/Gecko(107): NeckoParent::AllocPHttpChannel: FATAL error: missing required PBrowser argument: KILLING CHILD PROCESS
01-22 20:32:15.646: I/Gecko(107): ###!!! [Parent][AsyncChannel] Error: Value error: message was deserialized, but contained an illegal value
01-22 20:32:15.666: I/Gecko(107): ###!!! [Parent][AsyncChannel] Error: Channel error: cannot send/recv

Something blew sky high in the necko world.

Comment 14

[Jason Smith [:jsmith]]

And...this time I got a crash! Crash report coming...

Comment 15

[Jason Smith [:jsmith]]

Attachment: Logcat - Adnormal Tab Termination and Crash

Comment 16

[Jason Smith [:jsmith]]

Yup, this is most definitely something blowing up in the necko world:

https://crash-stats.mozilla.com/report/index/bp-e85bfc2e-a013-417d-ae9e-3f12f2130123

Your crash report as requested!

Comment 17

[Jason Smith [:jsmith]]

Pretty easy to reproduce too:

1. Go to wired.com in the browser
2. View an article
3. Press the back button to return back to previous page
4. If you haven't crashed yet, try it with another article with steps #2 and #3

Seems to be quite to crash going through the about steps.

Comment 18

[Dale Harvey (:daleharvey)]

Unassigning myself since I am not really the best person to be debugging necko crashes

Comment 19

[Tarek Ziadé (:tarek)]

A great Jason, thanks a lot! I was desesperate because I could not reproduce it this morning and the logcat history was not going in the past enough.

Comment 20

[Jason Duell]

We've probably got at least two bugs here:

> required PBrowser argument: KILLING CHILD PROCESS

This means code *using* an HTTP channel was misbehaving by not passing security info (i.e. not setting a TabChild as the channel callbacks).   Not a necko bug.  We need to find the offending client code and fork a bug to fix it.

Let's keep this bug open for the parent process crash.  That's either a necko or IPDL bug.  It looks to me like a websockets issue: the crash report shows a (child-side) crash while trying to open a new WebSocket during the onclose() method of another websocket.   I suspect this might be bug 765738 (see also bug 602286).  We then (at end of the log) see a parent error: "[Parent][AsyncChannel] Error: Channel error: cannot send/recv" (which winds up calling OnProcessingError, which generally turns into a parent-side RUNTIMEABORT).  One likely culprit is if we don't check the IPDL connection for liveness on the parent before sending an IPDL message.

I'll look into this in a debugger tomorrow.  Alas it doesn't seem to happen on B2G desktop.

Comment 21

[Josh Matthews [:jdm]]

The error being demonstrated in the crash report is interesting; we're apparently trying to pass a PBrowser actor that is no longer alive as part of the PWebSocket constructor message. Also, when I reproduce crashes in the debugger, all I ever see is a SIGTERM in the child, then the chrome process stops showing any homescreen content.

Comment 22

[Justin Lebar (not reading bugmail)]

Okay, but all of these crashes are in the /child/ process, right?

I don't think we should block on child process crashes at this point, either, because it's trivial to crash the child process (just OOM it).

If OTOH we can crash the whole phone, as described earlier, that would be much more serious.

Comment 23

[Jason Smith [:jsmith]]

(In reply to Justin Lebar [:jlebar] from comment #22)
> Okay, but all of these crashes are in the /child/ process, right?
> 
> I don't think we should block on child process crashes at this point,
> either, because it's trivial to crash the child process (just OOM it).
> 
> If OTOH we can crash the whole phone, as described earlier, that would be
> much more serious.

I actually have a different rationale why this actually is important to fix for v1 (as in blocking), but I can't mention over bugzilla. I'll mention in triage and email you and few others.

Comment 24

[Jason Smith [:jsmith]]

Oh and btw - I confirmed that I can also get this to crash in the app version of this app. https://marketplace.firefox.com/app/wiredcom

Comment 25

[Jason Smith [:jsmith]]

Attachment: Logcat - App Adnormal Termination - No Crash

Comment 26

[Alex Keybl [:akeybl]]

tef+ since this a consistent instability issue in a top app, but we'd also be OK with a wired-specific server-side workaround instead of an in-product fix (as long as we think this issue won't be more prevalent post-release).

Comment 27

[Jason Smith [:jsmith]]

Broke out bug 833935 for the non-necko issue mentioned in comment 20.

Comment 28

[Jason Duell]

Jsmith: can you still see the OS crash?  I can't repro it on my debug phone build, nor on my desktop B2G build, using both wired.com in the browser and the wiredcom app.  Jsmith, can you still see this?  Maybe I need to use a non-debug build.

Even the app crash is fairly rare for me.

Comment 29

[Jason Smith [:jsmith]]

(In reply to Jason Duell (:jduell) from comment #28)
> Jsmith: can you still see the OS crash?  I can't repro it on my debug phone
> build, nor on my desktop B2G build, using both wired.com in the browser and
> the wiredcom app.  Jsmith, can you still see this?  Maybe I need to use a
> non-debug build.
> 
> Even the app crash is fairly rare for me.

Actually, I just managed to pull off a OS restart crash. Not easy, but possible. More info coming...

Comment 30

[Jason Smith [:jsmith]]

Okay, this just gets more weird. The OS restart crash might be a different bug:

https://crash-stats.mozilla.com/report/index/bp-5583f8e9-3aa5-4e62-a84f-101f42130124

This looks like something blowing up in the Graphics department.

Should I break that off into a different bug and keep this one as the necko crash?

Comment 31

[Jason Duell]

jsmith: Yeah, let's fork the graphics crash and keep this open in case there really is a necko parent crash here.  But I can't repro it so far, so this may be WORKSFORME unless someone can see it again, ideally with STR.  Do we want to flag qa-wanted, or do you think you've already tested enough?

Comment 32

[Jason Smith [:jsmith]]

I'll try again, but the repro steps that just got me a crash was the following:

1. Connect on a 2G connection (EDGE)
2. Go to wired.com
3. Select the first image to go to the first article
4. Hit the back button after it finishes loading

Result - crash.

Seems to crash reliably on my 1/24 build.

Comment 33

[Jason Smith [:jsmith]]

Hmm...so digging into this for a while, it seems to vary in reproducibility. Sometimes I can consistently reproduce it with the steps above a few times in a row, and then I can't reproduce it at all for a while.

Comment 34

[Jason Smith [:jsmith]]

Marcia and I dug into even further. Looks like this only reproduces on a data connection. Marcia & I couldn't reproduce this on a wifi connection at all.

Comment 35

[Tarek Ziadé (:tarek)]

I am going to try again on data only to see if I can get a reliable scenario

Comment 36

[Jason Duell]

Tried with data connection and crashed phone once.  Alas, not while I had my debugger attached.  And now I've tried a bunch and it's not happening again.  I'll keep trying--let me know if someone finds a reliable STR.

doesn't help that wired.com seems to take up 100% of cpu forever in my debug build.  Also I find that when I try to go back from an article, it winds up just going back to the same article.  meh :(

Comment 38

[Jason Duell]

It's likely that this will no longer happen as of bug 833935 being fixed, but only because child will behave better.  I'm going to keep trying to catch it in a pre-833935 build as I don't like parent crash opportunities to be present :)

Comment 39

[Jason Smith [:jsmith]]

(In reply to Jason Duell (:jduell) from comment #38)
> It's likely that this will no longer happen as of bug 833935 being fixed,
> but only because child will behave better.  I'm going to keep trying to
> catch it in a pre-833935 build as I don't like parent crash opportunities to
> be present :)

Sounds like we should no longer block on this then, right?

Comment 40

[Jason Duell]

Well, there's still a way to somehow crash the parent if the child process were to be compromised.  Not a very obvious way, though.

If we verify that as of this morning's landing we can no longer repro wired.com crashing (in either parent or child) then yes, I'd suggest we remove this as a blocker.

Comment 41

[David Scravaglieri [:scravag]]

Please renominate if you reproduce the crash again.

Comment 42

[Jason Duell]

I've been unable to replicate this parent crash despite browsing for quite a while on wired.com with a data (non-wifi) connection and an older build (pre-bug 833935 landing).  I'm going to mark WORKSFORME for now.

Comment 43

[Jason Smith [:jsmith]]

lgtm on 1/30 build.

Comment 44

[Tarek Ziadé (:tarek)]

I just crashed Firefox OS again on wired.com home page and was able to get a full log. incoming

Comment 45

[Tarek Ziadé (:tarek)]

Attachment: Full Firefox OS Crash - just by scrolling down wired.com home

That's with the 31.01 update.

I am able to reproduce it on every try

Comment 46

[Jason Smith [:jsmith]]

There's already a bug on the wired.com homepage crash. That's bug 834435.

Comment 47

[Tarek Ziadé (:tarek)]

sorry I did not pay attention to that