1143102 - Intermittent test_bug260264_nested.html | application crashed [@ mozalloc_abort(char const*)] with nsPipeInputStream on the stack

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[Ryan VanderMeulen [:RyanVM]]

Attachment: test log

See the attached log and comment 1 for more info.

Comment 1

[Legacy TBPL/Treeherder Robot]

log: https://treeherder.mozilla.org/logviewer.html#?repo=mozilla-inbound&job_id=7596570
repository: mozilla-inbound
start_time: 2015-03-13T10:42:29
who: rvandermeulen[at]mozilla[dot]com
machine: t-yosemite-r5-0029
buildname: Rev5 MacOSX Yosemite 10.10 mozilla-inbound debug test mochitest-3
revision: c05f34c01e6d

2816 ERROR TEST-UNEXPECTED-FAIL | dom/tests/mochitest/bugs/test_bug260264_nested.html | application terminated with exit code 1
PROCESS-CRASH | dom/tests/mochitest/bugs/test_bug260264_nested.html | application crashed [@ mozalloc_abort(char const*)]
TEST-UNEXPECTED-FAIL | leakcheck | default process: missing output line for total leaks!
Return code: 1
No tests run or test summary not found

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

This one is not obvious.  It appears a thread is blocked getting the monitor in nsPipeOutputStream::WriteSegments() while an nsPipeInputStream::AsyncWait() is releasing the monitor.  The thread releasing the monitor crashed during the release.

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

Nathan, this looks like memory corruption.  This is the second bug like this I've seen today.  (See bug 1142803.)  Any thoughts?  I don't see how this could happen under normal conditions in pipe.

Comment 4

[Nathan Froyd [:froydnj]]

Did we somehow destroy our pipe while we were waiting on it?  That's what comes to mind when things crash on a lock like that.  I wish Breakpad would print all the registers...

Comment 5

[Ben Kelly [:bkelly, not reviewing]]

The nsPipeInputStream::AsyncRead() accesses the monitor through an nsRefPtr<nsPipe>.  It seems the nsPipeInputStream itself would have to get destroyed for that to occur.  That seems unlikely since nsInputStreamPump::EnsureWaiting() calls AsyncRead() through an nsCOMPtr<>.

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

If this reproduces I can look at it.

Comment 7

[Ed Morley [:emorley]]

Inactive; closing (see bug 1180138).