The default bug view has changed. See this FAQ.

RegisterWaitForSingleObject from Chromium ObjectWatcher crashes in Visual Studio

RESOLVED FIXED in mozilla19

Status

()

Core
IPC
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: rmkn85, Assigned: rmkn85)

Tracking

14 Branch
mozilla19
x86_64
Windows 7
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

997 bytes, patch
Ben Turner (not reading bugmail, use the needinfo flag!)
: review+
Details | Diff | Splinter Review
(Assignee)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4

Steps to reproduce:

I ran a project with embedded XulRunner, using GeckoFX (https://bitbucket.org/geckofx/geckofx-14.0), in Visual Studio 2012, and loaded a website with Adobe Flash to the browser object.


Actual results:

Got the following error message, and page loading hanged, usually crashing my application:

"WARNING: RegisterWaitForSingleObject failed: 6: file e:/builds/moz2_slave/rel-m-rel-xr-w32-bld/build/ipc/chromium/src/base/object_watcher.cc, line 62"

The crash is from here:
http://lxr.mozilla.org/mozilla-central/source/ipc/chromium/src/base/object_watcher.cc#62


Expected results:

It should work without that error message, as it does when running as a standalone application and not from Visual Studio.

The bug is from the code borrowed from Chromium!
See Chromium bug about it:
http://code.google.com/p/chromium/issues/detail?id=131346

Someone reported that:
Exchanging WT_EXECUTEINWAITTHREAD for WT_EXECUTEDEFAULT resolves the issue.
Component: General → IPC
(Assignee)

Comment 1

5 years ago
Created attachment 674666 [details] [diff] [review]
RegisterWaitForSingleObject - don't ExecuteInWaitThread

http://msdn.microsoft.com/en-us/library/windows/desktop/ms685061(v=vs.85).aspx

"The callback function is invoked by the wait thread itself. This flag should be used only for short tasks or it could affect other wait operations.
Deadlocks can occur if some other thread acquires an exclusive lock and calls the UnregisterWait or UnregisterWaitEx function while the callback function is trying to acquire the same lock."

Sometimes it indeed deadlocks (specifically when debugging from Visual Studio), so this flags should no be used.

Updated

5 years ago
Attachment #674666 - Flags: review?(jones.chris.g)
Comment on attachment 674666 [details] [diff] [review]
RegisterWaitForSingleObject - don't ExecuteInWaitThread

This exceeds my win32-fu.
Attachment #674666 - Flags: review?(jones.chris.g) → review?(bent.mozilla)
Comment on attachment 674666 [details] [diff] [review]
RegisterWaitForSingleObject - don't ExecuteInWaitThread

Review of attachment 674666 [details] [diff] [review]:
-----------------------------------------------------------------

After reading the docs I think this is fine.
Attachment #674666 - Flags: review?(bent.mozilla) → review+

Comment 4

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/01f5586d2200
Assignee: nobody → rmkn85
https://hg.mozilla.org/mozilla-central/rev/01f5586d2200
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
You need to log in before you can comment on or make changes to this bug.