IPDLParamTraits<nsTArray<T>> doesn't work if T = RefPtr<U>
Categories
(Core :: IPC, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox69 | --- | fixed |
People
(Reporter: farre, Assigned: nika)
Details
Attachments
(2 files)
BrowsingContext
is refcounted, and using BrowsingContext[]
would trigger us using IPDLParamTraits<nsTArray<RefPtr<BrowsingContext>>::WriteInternal
which moves the elements of the array into WriteIPDLParam
which in turn tries to invoke BrowsingContext::~delete
and that is deleted due to it being refcounted.
That is, if we have:
template <typename T>
struct Strip {
typedef T Type;
};
template <typename T>
struct Strip<RefPtr<T>> {
typedef T Type;
};
template <typename T>
static void Baz(T* a) {
}
template <typename T>
struct Foo {
template <typename U>
static void Bar(U&& a) {
Baz<typename Strip<T>::Type>(std::forward<U>(a));
}
};
static void Qux() {
RefPtr<BrowsingContext> c;
Foo<RefPtr<BrowsingContext>>::Bar(std::move(c));
}
stuff breaks.
Reporter | ||
Updated•6 years ago
|
Updated•6 years ago
|
Comment 1•6 years ago
|
||
Seems like a defect to me if valid/reasonable IPDL results in invalid C++.
Assignee | ||
Comment 2•6 years ago
|
||
I think this is caused by some unfortunate fallout from the way we perform IPDLParamTraits
selection.
I have a local patch which flips around how we handle refcounted type selection here, which should make the behaviour for nsTArray<T> and other compound types perform better.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 3•6 years ago
|
||
Assignee | ||
Comment 4•6 years ago
|
||
Comment 5•6 years ago
|
||
The priority flag is not set for this bug.
:jld, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 6•6 years ago
|
||
This has r+'ed patches; is there anything else that needs to happen to land this?
Assignee | ||
Comment 7•6 years ago
|
||
This bug is currently on the stack after my changes in bug 1540731, which until very recently were blocked on :froydnj's review. My current intention is to not land any of these changes until after the merge, to minimize the chance of fallout.
Comment 8•6 years ago
|
||
The priority flag is not set for this bug.
:jld, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•6 years ago
|
Comment 10•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/15b4b7f9d97a
https://hg.mozilla.org/mozilla-central/rev/a50b68e0deb2
Description
•