Loic Reporter
	Description • 9 years ago

This bug was filed from the Socorro interface and is 
report bp-8e8c2c6d-5045-4e6b-95a6-f6da92150604.
=============================================================

Be sure e10s is enabled.
STR:
1) Open the large image http://www.imagebam.com/image/b05156413493542
2) Click fastly (~ 1/0.5 sec) repeatedly on the image to enlarge/reduce it.
IMPORTANT: At each click, click on a different place of the image.
NB: some ad pop-ups can appear on the click event, just go back to the tab and continue to click.


Result:
After a few clicks (~5), the image "freezes" and the tab crashes.
Same result if HWA is disabled.

Regression range:
good=2015-04-17
bad=2015-04-18
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=51e3cb11a258&tochange=8af644c9b616

Maybe bug 1146214.

	Alice0775 White
	Comment 1 • 9 years ago

Be sure e10s is enabled.
STR:
1) Open http://www.imagebam.com/image/b05156413493542
2) Drag the image and drop onto the image
3) Wait a few seconds

Actual Results:
Crash
bp-a4391c90-8963-4d41-be20-ff2142150604

Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ffd1b16f058b&tochange=4ddadc870ef6

Regressed by: Bug 1071562

	jen strickland :jenstrickland
	Comment 2 • 9 years ago

Enabled tracking for 40 and 41, because crashes.  I don't have privileges to change the flag for e10s, so needing info from Liz.

	Neil Deakin
	Comment 3 • 9 years ago

Don't know the specifics of the code that is crashing, but the image here is very large (1.6MB file and 7000x9000x pixels size). That, I think, works out to 252MB of data sent over a message.

	Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)
	Comment 4 • 9 years ago

The e10s team does their own triage to set priorities on their bugs, so I'm clearing needinfo. We do want to track this since it's a regression. Thanks Jen!

	Tobias B. Besemer [:BesTo] (QA)
	Comment 5 • 9 years ago

https://crash-stats.mozilla.com/report/index/54230516-3603-411d-9b11-454d22150609

	Tobias B. Besemer [:BesTo] (QA)
	Comment 6 • 9 years ago

> Component: mozglue → IPC

Was thinking the first frame in a crash report defines the component the crash belongs to ... ???

Crashing Thread
Frame 	Module 	Signature 	Source
0 	mozglue.dll 	mozalloc_abort(char const* const) 	memory/mozalloc/mozalloc_abort.cpp
1 	xul.dll 	NS_DebugBreak 	xpcom/base/nsDebugImpl.cpp
2 	xul.dll 	mozilla::ipc::MessageChannel::OnChannelErrorFromLink() 	ipc/glue/MessageChannel.cpp
3 	xul.dll 	mozilla::ipc::ProcessLink::OnChannelError() 	ipc/glue/MessageLink.cpp
4 	xul.dll 	IPC::Channel::ChannelImpl::OnIOCompleted(base::MessagePumpForIO::IOContext*, unsigned long, unsigned long) 	ipc/chromium/src/chrome/common/ipc_channel_win.cc
5 	xul.dll 	base::MessagePumpForIO::WaitForIOCompletion(unsigned long, base::MessagePumpForIO::IOHandler*) 	ipc/chromium/src/base/message_pump_win.cc
6 	xul.dll 	base::MessagePumpForIO::DoRunLoop() 	ipc/chromium/src/base/message_pump_win.cc
7 	xul.dll 	base::MessagePumpWin::Run(base::MessagePump::Delegate*) 	ipc/chromium/src/base/message_pump_win.h
8 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc
9 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc
10 	xul.dll 	base::Thread::ThreadMain() 	ipc/chromium/src/base/thread.cc
11 	xul.dll 	`anonymous namespace'::ThreadFunc(void*) 	ipc/chromium/src/base/platform_thread_win.cc
12 	kernel32.dll 	BaseThreadInitThunk 	
13 	ntdll.dll 	RtlUserThreadStart 	
14 	kernel32.dll 	BasepReportFault 	
15 	kernel32.dll 	BasepReportFault

https://crash-stats.mozilla.com/report/index/54230516-3603-411d-9b11-454d22150609

	Mike Hommey [:glandium]
	Comment 7 • 9 years ago

mozalloc_abort and NS_DebugBreak are functions called to crash on purpose, for some value of on purpose. mozalloc_abort is the one actually crashing. NS_DebugBreak is something that uses mozalloc_abort to crash, and it is used by macros like NS_RUNTIMEABORT, NS_WARN_IF_FALSE etc. where some of those will only call NS_DebugBreak on debug builds.
Anyways, what this all means is that it's whatever is above them in the stack that's at fault.

	Kate Glazko
	Comment 8 • 9 years ago

Assigning to Mike Hommey because every tracked bug should be assigned. Feel free to reassign to someone else.

	Mike Hommey [:glandium]
	Comment 9 • 9 years ago

That would be for some peer of the IPC module. Picking one at random.

	Sylvestre Ledru [:Sylvestre]
	Comment 10 • 9 years ago

Untracking for 40 as e10s won't be available in beta.

	Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)
	Comment 11 • 9 years ago

Jim, this is another e10 crash (though not top crash) which needs an owner. I don't see much dev activity on it in the last month or so. Thanks!

	Jim Mathies [:jimm]
	Comment 12 • 9 years ago

(In reply to Ritu Kothari (:ritu) from comment #11)
> Jim, this is another e10 crash (though not top crash) which needs an owner.
> I don't see much dev activity on it in the last month or so. Thanks!

This was flagged by the e10s team on 6-9, Blake will take a look at it at some point here.

	alex_mayorga
	Comment 13 • 9 years ago

FWIW Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:42.0) Gecko/20100101 Firefox/42.0 ID:20150712030212 CSet: eab21ec484bb crashes like

Report ID 	Date Submitted
bp-ca9d4e0d-b248-4868-80f2-aa8532150713
	13/07/2015	06:58 a.m.

I was showing https://bugzilla.mozilla.org/show_bug.cgi?id=1144063 to some folks in the LATAM QA meetup.

	none11given
	Comment 14 • 9 years ago

After clicking on the image repeatedly in Developer Edition 42.0a2, ALL my tabs crashed. Not the browser, but each individual tab. That probably shouldn't happen?

	Emanuel Hoogeveen [:ehoogeveen]
	Comment 15 • 9 years ago

At the moment, the default configuration for e10s only uses 1 content process. So if one tab causes a crash, all tabs will crash. You can increase the number of content processes by adjusting dom.ipc.processCount, but note that this is not a supported configuration yet (and tabs aren't spread out across content processes in a particularly principled way).

	Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)
	Comment 16 • 9 years ago

Untracked and wontfix'd for FF41 as e10s is not enabled by default. FF42+

	Sylvestre Ledru [:Sylvestre]
	Comment 17 • 9 years ago

Not tracking it anymore as we are going to disable e10s soon in aurora but tracking for 43.

	Tracy Walker [:tracy]
	Comment 18 • 9 years ago

This crash is quite low in volume except on 40.0.x. removing needinfo to get back into triage.

	Brad Lassey [:blassey] (use needinfo?)
	Comment 19 • 9 years ago

not tracking since its low volume. renom if it comes up in frequency

	Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)
	Comment 20 • 9 years ago

Very low volume across all channels. Untracking this for now.

	Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]
	Comment 21 • 8 years ago

I managed to reproduce this issue on the latest Aurora(46.0a2) on Windows 7 x32. If e10s is enabled, repeatedly clicking the image on different positions causes the crash. If e10s is disabled Firefox does not encounter any crash.

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160209004008

	Valentin Gosu [:valentin] (he/him)
	Comment 22 • 8 years ago

This test always crashes the child process on e10s.
I run it on local host, and it does a blob XHR for a file named test.zip - a file that is 1.1 Gb in size.

https://crash-stats.mozilla.com/report/index/febbbc9c-766f-4946-9569-8e9572160215

I've also had crashes on non-e10s, when doing multiple XHRs in a limited ammount of time, the process is killed with SIGKILL, but that's probably a different bug.

	Jukka Jylänki
	Comment 23 • 8 years ago

https://crash-stats.mozilla.com/report/index/b93ea76a-3144-4996-a1f4-ac6182160506

Occurred when viewing IndexedDB content in the Storage developer tool.

	Bill McCloskey [inactive unless it's an emergency] (:billm)
	Comment 24 • 8 years ago

I think this used to be how we would crash when messages were too large. Now we crash more directly. The original problem should be addressed by bug 1272018.

	Andrew McCreight [:mccr8]
	Comment 25 • 8 years ago

This crash still happens on Nightly, though not very often.

	Andrew McCreight [:mccr8]
	Comment 26 • 8 years ago

I'm going to mark this one dependent on bug 1272018, based on the STR in comment 0 and 1.

	BugBot [:suhaib / :marco/ :calixte]
	Comment 27 • 8 years ago

Crash volume for signature 'mozalloc_abort | NS_DebugBreak | mozilla::ipc::MessageChannel::OnChannelErrorFromLink':
 - nightly (version 50): 67 crashes from 2016-06-06.
 - aurora  (version 49): 66 crashes from 2016-06-07.
 - beta    (version 48): 6 crashes from 2016-06-06.
 - release (version 47): 6 crashes from 2016-05-31.
 - esr     (version 45): 0 crash from 2016-04-07.

Crash volume on the last weeks:
             Week N-1   Week N-2   Week N-3   Week N-4   Week N-5   Week N-6   Week N-7
 - nightly          9          3          2          4         12         18         16
 - aurora           6          4          8         11         17         15          0
 - beta             0          2          0          0          2          1          0
 - release          0          1          0          1          2          0          1
 - esr              0          0          0          0          0          0          0

Affected platforms: Windows, Linux

	Henrik Skupin [:whimboo][⌚️UTC+2]
	Comment 28 • 8 years ago

We already track this crash on bug 1051567.

	Loic Reporter
	Comment 29 • 8 years ago

(In reply to Henrik Skupin (:whimboo) from comment #28)
> We already track this crash on bug 1051567.
> 
> *** This bug has been marked as a duplicate of bug 1051567 ***

I disagree with your duping, because this bug has STR (see comment #1) and regressed by bug 1071562 which landed in FF40. But the crash signature looks pretty generic and can be found in versions prior to FF40.
In addition, the crash is partially fixed after bug 1272018 but there is still an issue (I'll file a new bug).

	Loic Reporter
	Comment 30 • 8 years ago

I've filed bug 1295272 for the remaining issue.

	BugBot [:suhaib / :marco/ :calixte]
	Comment 31 • 8 years ago

Crash volume for signature 'mozalloc_abort | NS_DebugBreak | mozilla::ipc::MessageChannel::OnChannelErrorFromLink':
 - nightly (version 51): 27 crashes from 2016-08-01.
 - aurora  (version 50): 71 crashes from 2016-08-01.
 - beta    (version 49): 29 crashes from 2016-08-02.
 - release (version 48): 4 crashes from 2016-07-25.
 - esr     (version 45): 0 crashes from 2016-05-02.

Crash volume on the last weeks (Week N is from 08-22 to 08-28):
            W. N-1  W. N-2  W. N-3
 - nightly       3      16       4
 - aurora       35      21       9
 - beta          4      16       9
 - release       0       2       0
 - esr           0       0       0

Affected platforms: Windows, Linux

Crash rank on the last 7 days:
           Browser   Content     Plugin
 - nightly           #117
 - aurora  #201      #117
 - beta    #12608    #2742
 - release           #329
 - esr

	Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)
	Comment 32 • 8 years ago

This is tracked in bug 1295272. Marking "fix optional" in this bug only to get it off our triage lists and focus on 1295272.