Closed Bug 556194 Opened 15 years ago Closed 15 years ago

Use-after-free of PluginInstanceChild.mAsyncCallMutex; crash [@mozilla::BlockingResourceBase::CheckAcquire] or [@ mozilla::DeadlockDetector<mozilla::BlockingResourceBase::DeadlockDetectorEntry>::CheckAcquisition] or [@ RtlEnterCriticalSection ]

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(blocking2.0 final+)

Status:
RESOLVED FIXED
Milestone:
mozilla2.0b8
Tracking Flags:
Tracking Status
blocking2.0 --- final+

People

(Reporter: cjones, Assigned: benjamin)

References

Details

(4 keywords)

Crash Data

Attachments

(1 file, 7 obsolete files)

Clear after calling NPP_Destroy, rev. 2 (for real)
1.82 KB, patch
cjones
: review+
Details | Diff | Splinter Review
Different bug exposed by the fix for bug 542700. http://tinderbox.mozilla.org/showlog.cgi?tree=Firefox&errorparser=unittest&logfile=1270007306.1270009110.2283.gz&buildtime=1270007306&buildname=WINNT%205.2%20mozilla-central%20debug%20test%20mochitests-3%2f5&fulltext=1#err1 http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1269981601.1269984069.28680.gz#err1 I think this may be due a race between NPN_AsyncCall and clearing the child array. For example, main thread other thread ------------------ -------------- AnswerNPP_Destroy [event] [delete and cancel async calls] NPN_AsyncCall delete instance AsyncCall::Run BOOM To avoid this, I think we need to set a flag before deleting the pending async calls that prevents later ones from being enqueued.
Blocks: 438871
Severity: normal → critical
Whiteboard: [orange]
Oops, in comment 0 the AsyncCall::Run is on the wrong thread. Same race condition though. (Run() doesn't matter except that it runs after ~PluginInstanceChild.) What I've found is that in general, we're going to have to rely on NPP_Destroy() being a synchronization point in plugins for their threads: after NPP_Destroy(), the other threads must no longer request async callbacks or be in the process of requesting async callbacks. Even if we relax that requirement to "no longer request async callbacks", that is, try to deal with plugin threads still in NPN_RequestAsyncCallback() or just before it when NPP_Destroy() returns, the problem gets quite hard. I don't think we can prevent PluginInstanceParent memory from being touched after being freed, but I think it may be possible to prevent callbacks from being invoked assuming the memory hasn't been reallocated yet. Need a model checker to sort that out though. I've got a fix in hand that's correct if we assume plugins follow the NPP_Destroy()-as-synchronization-point rule, but I suspect numerous plugin bugs abound in the wild. (Not judging, it's hard; we got it wrong!) I'll play with some mitigating factors tomorrow.
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1270027711.1270029366.26255.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/03/31 02:28:31 s: win32-slave39
Attached file Promela model of current code (obsolete) —
Assignee: nobody → jones.chris.g
Attached file Error found by spin (obsolete) —
Comment 0, essentially.
Attached file Promela model of current code (obsolete) —
Oops, on second glance the first model was allowed a trivial assertion failure: thread "starting" after NPP_Destroy().
Attachment #436379 - Attachment is obsolete: true
Attachment #436381 - Attachment is obsolete: true
Skipping the v2 that relies on plugins synchronizing at NPP_Destroy() because there are obvious ways bad things can happen if plugin threads don't do this.
I played around with some protection schemes with the current async call design, but I decided to follow Edsgar Dijkstra's advice instead "Any problem in computer science can be solved with another layer of indirection." This patch enqueues async calls that reference plugin instance IDs, and checks that the ID is still valid before running the callback. It would be better to summarily make |NPP->ndata| be the plugin ID, but this means that plugins not using NPN_AsyncCall pay a table lookup penalty for every NPN_* call. I doubt this would have any perf impact in practice, but as this fix only guards against buggy plugins, I decided to go with the more optimistic approach.
Attachment #436382 - Attachment is obsolete: true
Attachment #436384 - Attachment is obsolete: true
Attachment #436517 - Flags: review?(benjamin)
Attachment #436517 - Flags: review?(benjamin) → review-
Comment on attachment 436517 [details] [diff] [review] Refer to plugins by IDs in NPN_AsyncCall I really don't like this. I think we should trust that plugins will not call NPN_AsyncCall after returning from NPP_Destroy. We also should make sure that all the pending async calls are called before we enter NPP_Destroy, as OnPluginDestroy does, http://mxr.mozilla.org/mozilla-central/source/modules/plugin/base/src/nsNPAPIPlugin.cpp#950 The instance IDs seem like a weird abstraction which depends partly on the order in which memory is scribbled after the plugin instance has been destroyed.
OK, I disagree.
Assignee: jones.chris.g → benjamin
(In reply to comment #9) > (From update of attachment 436517 [details] [diff] [review]) > We also should make sure that > all the pending async calls are called before we enter NPP_Destroy, as > OnPluginDestroy does, Appears to me that this code is invalidating all pending calls. I don't see it calling Run() anywhere.
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1270164945.1270166855.10043.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/04/01 16:35:45 s: win32-slave31
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1270483400.1270485877.12456.gz&fulltext=1#err0 0 xul.dll!mozilla::BlockingResourceBase::CheckAcquire(mozilla::CallStack const &) [BlockingResourceBase.cpp:72c7b128abaa : 130 + 0x6] eip = 0x01462c39 esp = 0x0415fc7c ebp = 0x0415fcf4 ebx = 0x00000000 esi = 0x00000000 edi = 0x00000000 eax = 0x03eae904 ecx = 0xdddddddd edx = 0x00000000 efl = 0x00010286 Found by: given as instruction pointer in context 1 xul.dll!mozilla::Mutex::Lock() [BlockingResourceBase.cpp:72c7b128abaa : 260 + 0xb] eip = 0x014631e3 esp = 0x0415fcfc ebp = 0x0415fd08 Found by: call frame info 2 xul.dll!mozilla::MutexAutoLock::MutexAutoLock(mozilla::Mutex &,mozilla::GuardObjectNotifier const &) [Mutex.h:72c7b128abaa : 182 + 0x9] eip = 0x0043b4b1 esp = 0x0415fd10 ebp = 0x0415fd14 Found by: call frame info 3 xul.dll!mozilla::plugins::ChildAsyncCall::Run() [ChildAsyncCall.cpp:72c7b128abaa : 67 + 0x30] eip = 0x013d3ee2 esp = 0x0415fd1c ebp = 0x0415fd50 Found by: call frame info 4 xul.dll!MessageLoop::RunTask(Task *) [message_loop.cc:72c7b128abaa : 336 + 0xc] eip = 0x014c8c7e esp = 0x0415fd58 ebp = 0x0415fd78 Found by: call frame info 5 xul.dll!MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const &) [message_loop.cc:72c7b128abaa : 344 + 0xd] eip = 0x014c8cee esp = 0x0415fd80 ebp = 0x0415fd88 Found by: call frame info 6 xul.dll!MessageLoop::DoWork() [message_loop.cc:72c7b128abaa : 444 + 0xb] eip = 0x014c90cd esp = 0x0415fd90 ebp = 0x0415fdb4 Found by: call frame info 7 xul.dll!base::MessagePumpForUI::DoRunLoop() [message_pump_win.cc:72c7b128abaa : 209 + 0x1a] eip = 0x01501173 esp = 0x0415fdbc ebp = 0x0415fdc8 Found by: call frame info Noticed this today on tinderbox. Looks like the same issue.
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1270590569.1270593144.26226.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/04/06 14:49:29 s: win32-slave06
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1270678061.1270679975.2569.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/04/07 15:07:41 s: win32-slave31
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1270719307.1270721028.18688.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/04/08 02:35:07 s: win32-slave31
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1270753689.1270755569.24214.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/04/08 12:08:09 s: win32-slave34
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1270759954.1270761746.11395.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/04/08 13:52:34 s: win32-slave34
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1270858745.1270860614.6925.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/04/09 17:19:05 s: win32-slave31
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1271424297.1271426535.32265.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/04/16 06:24:57 s: win32-slave29
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1271459016.1271460749.26034.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/04/16 16:03:36 s: win32-slave34
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1271503672.1271505288.25225.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/04/17 04:27:52 s: win32-slave34
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1271601665.1271603783.8706.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/04/18 07:41:05 s: win32-slave29
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1271864952.1271866634.10135.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/04/21 08:49:12 s: win32-slave34
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1272147750.1272149915.8958.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/04/24 15:22:30 s: win32-slave08
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1272469361.1272470975.28458.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/04/28 08:42:41 s: win32-slave38
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1272525494.1272527824.32538.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/04/29 00:18:14 s: win32-slave08
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1272754352.1272756428.30818.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/05/01 15:52:32 s: win32-slave18
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1272757302.1272759517.5611.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/05/01 16:41:42 s: win32-slave18
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1272840584.1272842776.30348.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/05/02 15:49:44 s: win32-slave02
http://tinderbox.mozilla.org/showlog.cgi?log=TraceMonkey/1273031102.1273033380.21035.gz WINNT 5.2 tracemonkey debug test mochitests-3/5 on 2010/05/04 20:45:02 s: win32-slave57
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1273839941.1273841586.23423.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/05/14 05:25:41 s: win32-slave25
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1274242348.1274245002.12740.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/05/18 21:12:28 s: win32-slave14 Thread 0 (crashed) 0 xul.dll!mozilla::DeadlockDetector<mozilla::BlockingResourceBase::DeadlockDetectorEntry>::CheckAcquisition(mozilla::BlockingResourceBase::DeadlockDetectorEntry const *,mozilla::BlockingResourceBase::DeadlockDetectorEntry const *,mozilla::CallStack const &) [DeadlockDetector.h:6108e2debf9e : 436 + 0x3] eip = 0x0144afc4 esp = 0x0012efe4 ebp = 0x0012f03c ebx = 0x00000000 esi = 0x03f13720 edi = 0x00000000 eax = 0x03f15a78 ecx = 0x00000000 edx = 0x00000000 efl = 0x00010216 Found by: given as instruction pointer in context 1 xul.dll!mozilla::BlockingResourceBase::CheckAcquire(mozilla::CallStack const &) [BlockingResourceBase.cpp:6108e2debf9e : 140 + 0x31] eip = 0x0144a54c esp = 0x0012f044 ebp = 0x0012f0c8 Found by: call frame info 2 xul.dll!mozilla::Mutex::Lock() [BlockingResourceBase.cpp:6108e2debf9e : 260 + 0xb] eip = 0x0144aa93 esp = 0x0012f0d0 ebp = 0x0012f0dc Found by: call frame info
Summary: Use-after-free of PluginInstanceChild.mAsyncCallMutex; crash [@mozilla::BlockingResourceBase::CheckAcquire] → Use-after-free of PluginInstanceChild.mAsyncCallMutex; crash [@mozilla::BlockingResourceBase::CheckAcquire] or [@ mozilla::DeadlockDetector<mozilla::BlockingResourceBase::DeadlockDetectorEntry>::CheckAcquisition]
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1274474723.1274476395.12006.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/05/21 13:45:23 0 xul.dll!mozilla::BlockingResourceBase::CheckAcquire(mozilla::CallStack const &) [BlockingResourceBase.cpp:3af8b1f39ee8 : 130 + 0x6] eip = 0x0144cb29 esp = 0x0012f050 ebp = 0x0012f0c8 ebx = 0x00000000 esi = 0x03f33720 edi = 0x00000000 eax = 0x03f53d84 ecx = 0x00000000 edx = 0x00000000 efl = 0x00010282 Found by: given as instruction pointer in context 1 xul.dll!mozilla::Mutex::Lock() [BlockingResourceBase.cpp:3af8b1f39ee8 : 260 + 0xb] eip = 0x0144d0d3 esp = 0x0012f0d0 ebp = 0x0012f0dc Found by: call frame info 2 xul.dll!mozilla::MutexAutoLock::MutexAutoLock(mozilla::Mutex &,mozilla::GuardObjectNotifier const &) [Mutex.h:3af8b1f39ee8 : 182 + 0x9] eip = 0x0043b301 esp = 0x0012f0e4 ebp = 0x0012f0e8 Found by: call frame info 3 xul.dll!mozilla::plugins::ChildAsyncCall::RemoveFromAsyncList() [ChildAsyncCall.cpp:3af8b1f39ee8 : 67 + 0x30] eip = 0x013c5cf2 esp = 0x0012f0f0 ebp = 0x0012f124 Found by: call frame info 4 xul.dll!mozilla::plugins::ChildAsyncCall::Run() [ChildAsyncCall.cpp:3af8b1f39ee8 : 75 + 0x7] eip = 0x013c5d4f esp = 0x0012f12c ebp = 0x0012f130 Found by: call frame info 5 xul.dll!MessageLoop::RunTask(Task *) [message_loop.cc:3af8b1f39ee8 : 336 + 0xc] eip = 0x014b44be esp = 0x0012f138 ebp = 0x0012f158 Found by: call frame info 6 xul.dll!MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const &) [message_loop.cc:3af8b1f39ee8 : 344 + 0xd] eip = 0x014b452e esp = 0x0012f160 ebp = 0x0012f168 Found by: call frame info 7 xul.dll!MessageLoop::DoWork() [message_loop.cc:3af8b1f39ee8 : 444 + 0xb] eip = 0x014b490d esp = 0x0012f170 ebp = 0x0012f194 Found by: call frame info 8 xul.dll!base::MessagePumpForUI::DoRunLoop() [message_pump_win.cc:3af8b1f39ee8 : 213 + 0x1a] eip = 0x014eca63 esp = 0x0012f19c ebp = 0x0012f1a8 Found by: call frame info 9 xul.dll!base::MessagePumpWin::RunWithDispatcher(base::MessagePump::Delegate *,base::MessagePumpWin::Dispatcher *) [message_pump_win.cc:3af8b1f39ee8 : 52 + 0xc] eip = 0x014ec4bf esp = 0x0012f1b0 ebp = 0x0012f1cc ebx = 0x7ffff000 Found by: call frame info 10 xul.dll!base::MessagePumpWin::Run(base::MessagePump::Delegate *) [message_pump_win.h:3af8b1f39ee8 : 78 + 0x14] eip = 0x014ec6f5 esp = 0x0012f1d4 ebp = 0x0012f1e0 Found by: call frame info 11 xul.dll!MessageLoop::RunInternal() [message_loop.cc:3af8b1f39ee8 : 216 + 0x1e] eip = 0x014b3f96 esp = 0x0012f1e8 ebp = 0x0012f204 Found by: call frame info 12 xul.dll!MessageLoop::RunHandler() [message_loop.cc:3af8b1f39ee8 : 192 + 0x7] eip = 0x014b3ea8 esp = 0x0012f20c ebp = 0x0012f23c Found by: call frame info 13 xul.dll!MessageLoop::Run() [message_loop.cc:3af8b1f39ee8 : 173 + 0x7] eip = 0x014b3db3 esp = 0x0012f244 ebp = 0x0012f26c ebx = 0x0012ec5c Found by: call frame info 14 xul.dll!XRE_InitChildProcess [nsEmbedFunctions.cpp:3af8b1f39ee8 : 414 + 0xa] eip = 0x0041c8a4 esp = 0x0012f274 ebp = 0x0012ff0c Found by: call frame info 15 plugin-container.exe!NS_internal_main(int,char * *) [MozillaRuntimeMain.cpp:3af8b1f39ee8 : 87 + 0x14] eip = 0x00401807 esp = 0x0012ff14 ebp = 0x0012ff34 Found by: call frame info 16 plugin-container.exe!wmain [nsWindowsWMain.cpp:3af8b1f39ee8 : 120 + 0xc] eip = 0x004011b9 esp = 0x0012ff3c ebp = 0x0012ff68 Found by: call frame info 17 plugin-container.exe!__tmainCRTStartup [crtexe.c : 594 + 0x18] eip = 0x00401b96 esp = 0x0012ff70 ebp = 0x0012ffb8 Found by: call frame info 18 plugin-container.exe!wmainCRTStartup [crtexe.c : 413 + 0x4] eip = 0x004019ed esp = 0x0012ffc0 ebp = 0x0012ffc0 ebx = 0x0012ec5c Found by: call frame info 19 kernel32.dll + 0x2f23a eip = 0x77e6f23b esp = 0x0012ffc8 ebp = 0x0012fff0 Found by: call frame info
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1274476190.1274478684.21904.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/05/21 14:09:50 s: win32-slave20
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1274670048.1274672278.18808.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/05/23 20:00:48 s: win32-slave23
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1274677920.1274680116.19091.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/05/23 22:12:00 s: win32-slave23
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1274737637.1274739538.14236.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/05/24 14:47:17 s: win32-slave41
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1274775242.1274777772.13141.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/05/25 01:14:02
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1274896638.1274898936.28661.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/05/26 10:57:18 s: win32-slave06
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1275177999.1275179651.18880.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/05/29 17:06:39 s: win32-slave36
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1275196817.1275198994.26558.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/05/29 22:20:17 s: win32-slave19
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1275291524.1275293071.4776.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/05/31 00:38:44
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1275327750.1275329313.30533.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/05/31 10:42:30 s: win32-slave36
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1275428182.1275431007.17229.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/01 14:36:22 s: win32-slave19
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1275622907.1275625213.21064.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/03 20:41:47 s: win32-slave18
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1275679227.1275681841.27574.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/04 12:20:27 s: win32-slave19
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1275701136.1275703319.27866.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/04 18:25:36 s: win32-slave10
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1275790734.1275792915.18211.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/05 19:18:54 s: win32-slave18
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1275850538.1275852760.29591.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/06 11:55:38 s: win32-slave18
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1276024516.1276026214.10362.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/08 12:15:16 s: win32-slave40
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1276051524.1276053268.8672.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/08 19:45:24 s: win32-slave40
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1276322460.1276324210.19186.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/11 23:01:00 s: win32-slave37
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1276650113.1276652571.7979.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/15 18:01:53 s: win32-slave07
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1276711111.1276713598.16897.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/16 10:58:31 s: win32-slave07
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1277127717.1277129364.22694.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/21 06:41:57 s: mw32-ix-slave21
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1277160511.1277162890.23975.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/21 15:48:31 s: win32-slave27
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1277186423.1277189833.32333.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/21 23:00:23 s: win32-slave48
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1277230231.1277233107.8135.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/22 11:10:31 s: win32-slave48
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1277290098.1277292409.5960.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/23 03:48:18 s: win32-slave27
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1277311438.1277313623.29120.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/23 09:43:58 s: win32-slave34
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1277399017.1277401558.8359.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/24 10:03:37 s: win32-slave36
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1277480483.1277483360.9733.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/25 08:41:23 s: win32-slave44
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1277567001.1277569918.18314.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/26 08:43:21 s: win32-slave11
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1277703926.1277707106.21639.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/27 22:45:26 s: win32-slave11
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1277828020.1277830270.14968.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/29 09:13:40 s: win32-slave34
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1277839878.1277843642.9691.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/29 12:31:18 s: win32-slave44
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1277837900.1277840444.27074.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/29 11:58:20 s: win32-slave52
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1277840549.1277843642.9700.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/29 12:42:29 s: win32-slave50
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1277844089.1277846464.22942.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/29 13:41:29 s: win32-slave50
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1277941708.1277945128.31785.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/06/30 16:48:28 s: win32-slave56
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1278638988.1278641216.28629.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/07/08 18:29:48 s: win32-slave37
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1278912828.1278914958.30621.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 on 2010/07/11 22:33:48
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1280189822.1280192627.26117.gz s:win32-slave35, mozilla-central Win2k3 debug mochitest chunk 3.
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1280363357.1280366784.23594.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 [testfailed] Crash reason: EXCEPTION_ACCESS_VIOLATION Crash address: 0xffffffffdddddde1 Thread 0 (crashed) 0 xul.dll!mozilla::BlockingResourceBase::CheckAcquire(mozilla::CallStack const &) [BlockingResourceBase.cpp:c6673716fd47 : 130 + 0x6] eip = 0x01582039 esp = 0x0012f038 ebp = 0x0012f0b0 ebx = 0x00000000 esi = 0x041038b8 edi = 0x00000000 eax = 0x041213c0 ecx = 0xdddddddd edx = 0x00000000 efl = 0x00010202 Found by: given as instruction pointer in context 1 xul.dll!mozilla::Mutex::Lock() [BlockingResourceBase.cpp:c6673716fd47 : 260 + 0xb] eip = 0x015825e3 esp = 0x0012f0b8 ebp = 0x0012f0c4 Found by: call frame info ...
2 xul.dll!mozilla::MutexAutoLock::MutexAutoLock(mozilla::Mutex &,mozilla::GuardObjectNotifier const &) [Mutex.h:c6673716fd47 : 182 + 0x9] eip = 0x004399f1 esp = 0x0012f0cc ebp = 0x0012f0d0 Found by: call frame info 3 xul.dll!mozilla::plugins::ChildAsyncCall::RemoveFromAsyncList() [ChildAsyncCall.cpp:c6673716fd47 : 67 + 0x30] eip = 0x014a0a92 esp = 0x0012f0d8 ebp = 0x0012f10c Found by: call frame info ...
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1280522696.1280525789.27846.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 Thread 0 (crashed) 0 xul.dll!mozilla::BlockingResourceBase::CheckAcquire(mozilla::CallStack const &) [BlockingResourceBase.cpp:20fc55e14e9f : 130 + 0x6] eip = 0x01583539 esp = 0x0012f038 ebp = 0x0012f0b0 ebx = 0x00000000 esi = 0x04103678 edi = 0x00000000 eax = 0x04120bb8 ecx = 0xdddddddd edx = 0x00000000 efl = 0x00010286 Found by: given as instruction pointer in context 1 xul.dll!mozilla::Mutex::Lock() [BlockingResourceBase.cpp:20fc55e14e9f : 260 + 0xb] eip = 0x01583ae3 esp = 0x0012f0b8 ebp = 0x0012f0c4 Found by: call frame info 2 xul.dll!mozilla::MutexAutoLock::MutexAutoLock(mozilla::Mutex &,mozilla::GuardObjectNotifier const &) [Mutex.h:20fc55e14e9f : 182 + 0x9] eip = 0x00439d41 esp = 0x0012f0cc ebp = 0x0012f0d0 Found by: call frame info 3 xul.dll!mozilla::plugins::ChildAsyncCall::RemoveFromAsyncList() [ChildAsyncCall.cpp:20fc55e14e9f : 67 + 0x30] eip = 0x014a1dc2 esp = 0x0012f0d8 ebp = 0x0012f10c Found by: call frame info
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1281554082.1281558166.5351.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 A little odd that it didn't actually note a failure for the fact that the process crashed, only that there was no leak output. Thread 0 (crashed) 0 xul.dll!mozilla::BlockingResourceBase::CheckAcquire(mozilla::CallStack const eip = 0x009388a9 esp = 0x0012f020 ebp = 0x0012f098 ebx = 0x00000000 esi = 0x04473928 edi = 0x00000000 eax = 0x0448f650 ecx = 0xdddddddd edx = 0x00000000 efl = 0x00010282 Found by: given as instruction pointer in context 1 xul.dll!mozilla::Mutex::Lock() [BlockingResourceBase.cpp:e516c7c1cbb5 : 260 eip = 0x00938fa3 esp = 0x0012f0a0 ebp = 0x0012f0ac Found by: call frame info 2 xul.dll!mozilla::MutexAutoLock::MutexAutoLock(mozilla::Mutex &,mozilla::Guar eip = 0x0078c217 esp = 0x0012f0b4 ebp = 0x0012f0c8 Found by: call frame info 3 xul.dll!mozilla::plugins::ChildAsyncCall::RemoveFromAsyncList() [ChildAsyncC eip = 0x0078c122 esp = 0x0012f0d0 ebp = 0x0012f104 Found by: call frame info
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1282732806.1282737024.27427.gz WINNT 5.2 mozilla-central debug test mochitests-3/5 Thread 0 (crashed) 0 xul.dll!mozilla::DeadlockDetector<mozilla::BlockingResourceBase::DeadlockDetectorEntry>::CheckAcquisition(mozilla::BlockingResourceBase::DeadlockDetectorEntry const *,m eip = 0x00947e74 esp = 0x0012efb4 ebp = 0x0012f00c ebx = 0x00000000 esi = 0x044e3778 edi = 0x00000000 eax = 0x044e7c14 ecx = 0x00000000 edx = 0x00000000 efl = 0x00010212 Found by: given as instruction pointer in context 1 xul.dll!mozilla::BlockingResourceBase::CheckAcquire(mozilla::CallStack const &) [BlockingResourceBase.cpp:4a6ee9e82945 : 140 + 0x31] eip = 0x0094713c esp = 0x0012f014 ebp = 0x0012f098 Found by: call frame info 2 xul.dll!mozilla::Mutex::Lock() [BlockingResourceBase.cpp:4a6ee9e82945 : 260 + 0xb] eip = 0x009477d3 esp = 0x0012f0a0 ebp = 0x0012f0ac Found by: call frame info 3 xul.dll!mozilla::MutexAutoLock::MutexAutoLock(mozilla::Mutex &,mozilla::GuardObjectNotifier const &) [Mutex.h:4a6ee9e82945 : 182 + 0x9] eip = 0x00790977 esp = 0x0012f0b4 ebp = 0x0012f0c8 Found by: call frame info 4 xul.dll!mozilla::plugins::ChildAsyncCall::RemoveFromAsyncList() [ChildAsyncCall.cpp:4a6ee9e82945 : 67 + 0x30] eip = 0x00790882 esp = 0x0012f0d0 ebp = 0x0012f104 Found by: call frame info
blocking2.0: --- → final+
Attachment #436517 - Attachment is obsolete: true
Attachment #469127 - Flags: review?(jones.chris.g)
Comment on attachment 469127 [details] [diff] [review] use a flag, discard remaining async calls This patch doesn't fix anything. If we're going to trust plugins to use this subtle and poorly-specified API correctly, then all you need is diff --git a/dom/plugins/PluginInstanceChild.cpp b/dom/plugins/PluginInstanceChild.cpp --- a/dom/plugins/PluginInstanceChild.cpp +++ b/dom/plugins/PluginInstanceChild.cpp - { - MutexAutoLock lock(mAsyncCallMutex); - for (PRUint32 i = 0; i < mPendingAsyncCalls.Length(); ++i) - mPendingAsyncCalls[i]->Cancel(); - mPendingAsyncCalls.TruncateLength(0); - } - mTimers.Clear(); + // NPP_Destroy() should be a synchronization point for plugin + // threads that might request async calls from this instance: + // after this function returns, they are no longer allowed to + // request them. However, this is easy to get wrong, so we guard + // against use-after-free bugs by forcing async calls to prove + // that the instance from which they were requested is still live + // before they run. PluginModuleChild::current()->NPP_Destroy(this); plus an |mPendingAsyncCalls.Clear()| after the NPP_Destroy(this) and an updated comment.
Attachment #469127 - Flags: review?(jones.chris.g) → review-
Number of Crashing is increased by landing of Bug 596094. STR in Bug 614979 causes 100% crash.
Blocks: 596094
Adding the signature and keywords from the dupes then...
Keywords: crash, topcrash
Summary: Use-after-free of PluginInstanceChild.mAsyncCallMutex; crash [@mozilla::BlockingResourceBase::CheckAcquire] or [@ mozilla::DeadlockDetector<mozilla::BlockingResourceBase::DeadlockDetectorEntry>::CheckAcquisition] → Use-after-free of PluginInstanceChild.mAsyncCallMutex; crash [@mozilla::BlockingResourceBase::CheckAcquire] or [@ mozilla::DeadlockDetector<mozilla::BlockingResourceBase::DeadlockDetectorEntry>::CheckAcquisition] or [@ RtlEnterCriticalSection ]
So what's going on with this bug? It's pretty major, I used flash and YouTube a lot and my crash logs are absolutely filled with this crash.
I thought I had already attached this, but apparently not :-(
Attachment #469127 - Attachment is obsolete: true
Attachment #494777 - Flags: review?(jones.chris.g)
Comment on attachment 494777 [details] [diff] [review] Clear after calling NPP_Destroy, rev. 1 Wrong patch.
Attachment #494777 - Flags: review?(jones.chris.g)
argh
Attachment #494777 - Attachment is obsolete: true
Attachment #495579 - Flags: review?(jones.chris.g)
Comment on attachment 495579 [details] [diff] [review] Clear after calling NPP_Destroy, rev. 2 (for real) >+ for (PRUint32 i = 0; i < mPendingAsyncCalls.Length(); ++i) >+ mPendingAsyncCalls[i]->Cancel(); >+ >+ mPendingAsyncCalls.Clear(); >+ Probably worth adding a comment here about purposely dropping pending callbacks instead of running them, to match existing nsNPAPI* impl. Looks good.
Attachment #495579 - Flags: review?(jones.chris.g) → review+
http://hg.mozilla.org/mozilla-central/rev/f37d738ce296
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
My bug (614979) that was marked as a duplicate of this is still unfixed after this landed. STR: 1. Visit http://www.youtube.com/watch?v=Cj6ho1-G6tw 2. Set 1080p, set full screen, exit fullscreen 3. Reload page, Crash @ RtlEnterCriticalSection
> My bug (614979) that was marked as a duplicate of this is still unfixed after > this landed. This patch is going to be landed in 4.0b8pre/20101208 so it is normal it is not yet fixed in the current nightly.
(In reply to comment #216) > > My bug (614979) that was marked as a duplicate of this is still unfixed after > > this landed. > This patch is going to be landed in 4.0b8pre/20101208 so it is normal it is not > yet fixed in the current nightly. I was on an hourly.. just got the hourly as of now and it is still not fixed in 20101208025228
I can reproduce in 4.0b8pre/20101208 with the STR of comment 215.
Crash Signature: [@mozilla::BlockingResourceBase::CheckAcquire] [@ mozilla::DeadlockDetector<mozilla::BlockingResourceBase::DeadlockDetectorEntry>::CheckAcquisition] [@ RtlEnterCriticalSection ]
Whiteboard: [orange]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: