New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 739950 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Jan 2018
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Potential crasher in select_file_dialog_mac.mm

Project Member Reported by shrike@chromium.org, Jul 6 2017

Issue description

The issue is that the call to -beginSheetModalForWindow:completionHandler: passes a block that calls bridge_.get(), but it's not clear that bridge_.get() is retained. When setting up a block the objects that appear within the block are retained by the runtime but I suspect bridge_.get() doesn't look like something that needs to be retained.

Because -beginSheetModalForWindow:completionHandler: is asynchronous, SelectFileDialogImpl::SelectFileImpl() will return, and bridge_ (an ivar of SelectFileDialogImpl) will get destroyed soon after when FileSelectHelper::RunFileChooserOnUIThread() exits.
 

Comment 1 by shrike@chromium.org, Jan 18 2018

Status: WontFix (was: Assigned)
There's a further problem that the bridge calls back into the SelectFileDialogMac via a weak pointer. If we retain the bridge, the dialog may have been freed.

The FileWasSelected code cleans up after the file selection process, so likely that code triggers the free of the SelectFileDialog (i.e. the dialog sticks around until the file dialog exits with a file or a cancel).

Sign in to add a comment