Closed Bug 527871 Opened 15 years ago Closed 15 years ago

xpcshell tests failing on Windows

Categories

(Core :: IPC, defect)

Other Branch
x86
Windows NT
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: benjamin, Assigned: cjones)

References

Details

The ipcshell xpcshell tests are failing on Windows-debug because of assertions. They appear to be hanging on Tinderbox too, which may be the same bug or something different.

Relevant bits:
WARNING: Connect called twice: file c:/builds/electrolysis/ff-debug/ipc/chromium/../../../src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 175
...
WARNING: Connect called twice: file c:/builds/electrolysis/ff-debug/ipc/chromium/../../../src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 175
###!!! ABORT: not on IO thread!: 'mIOLoop == MessageLoop::current()', file c:\builds\electrolysis\ff-debug\dist\include\mozilla/ipc/AsyncChannel.h, line 142

nsXPConnect::CommenceShutdown()
xul!mozilla::ipc::AsyncChannel::OnClose+0x0000000000000030 (c:\builds\electrolysis\src\ipc\glue\asyncchannel.cpp, line 293)
xul!DispatchToMethod<mozilla::ipc::AsyncChannel,void (__thiscall mozilla::ipc::AsyncChannel::*)(void)>+0x000000000000000C (c:\builds\electrolysis\src\ipc\chromium\src\base\tuple.h, line 384)
xul!RunnableMethod<mozilla::ipc::AsyncChannel,void (__thiscall mozilla::ipc::AsyncChannel::*)(void),Tuple0>::Run+0x000000000000002E (c:\builds\electrolysis\src\ipc\chromium\src\base\task.h, line 307)
xul!MessageLoop::RunTask+0x000000000000004E (c:\builds\electrolysis\src\ipc\chromium\src\base\message_loop.cc, line 323)
xul!MessageLoop::DeferOrRunPendingTask+0x000000000000002E (c:\builds\electrolysis\src\ipc\chromium\src\base\message_loop.cc, line 333)
xul!MessageLoop::DoWork+0x00000000000000CD (c:\builds\electrolysis\src\ipc\chromium\src\base\message_loop.cc, line 430)
xul!base::MessagePumpForIO::DoRunLoop+0x0000000000000021 (c:\builds\electrolysis\src\ipc\chromium\src\base\message_pump_win.cc, line 446)
xul!base::MessagePumpWin::RunWithDispatcher+0x000000000000005F (c:\builds\electrolysis\src\ipc\chromium\src\base\message_pump_win.cc, line 54)
xul!base::MessagePumpWin::Run+0x0000000000000015 (c:\builds\electrolysis\src\ipc\chromium\src\base\message_pump_win.h, line 78)
xul!MessageLoop::RunInternal+0x0000000000000056 (c:\builds\electrolysis\src\ipc\chromium\src\base\message_loop.cc, line 212)
xul!MessageLoop::RunHandler+0x0000000000000082 (c:\builds\electrolysis\src\ipc\chromium\src\base\message_loop.cc, line 195)
xul!MessageLoop::Run+0x0000000000000043 (c:\builds\electrolysis\src\ipc\chromium\src\base\message_loop.cc, line 169)
xul!base::Thread::ThreadMain+0x0000000000000105 (c:\builds\electrolysis\src\ipc\chromium\src\base\thread.cc, line 168)
xul!`anonymous namespace'::ThreadFunc+0x0000000000000017 (c:\builds\electrolysis\src\ipc\chromium\src\base\platform_thread_win.cc, line 27)
kernel32!BaseThreadInitThunk+0x0000000000000012
ntdll!RtlInitializeExceptionChain+0x0000000000000063
ntdll!RtlInitializeExceptionChain+0x0000000000000036

I don't actually know which output comes from which process for certain.
The bug is a use-after-free, which ironically enough is being caught by a threadsafety assertion.  AsyncChannel's Close() logic is incorrect in this case, and easy to fix, but I want to see what's different about xpcshell's shutdown process such that it trips this error.
Fixed the assertion, now I'm seeing a leak.
Pushed http://hg.mozilla.org/projects/electrolysis/rev/8014289bdafb, which fixes the assertion and TestShellParent leak, but not the GeckoChildProcess one.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.